Clarification (function adapters)

[Geminias]

c++:

template < class Operation1, class Operation2, class Operation3 > class binary_compose : public unary_function< Operation2::argument_type,                                              Operation1::result_type > { protected:     Operation1 op1;     Operation2 op2;     Operation3 op3; public:     binary_compose(const Operation1& x, const Operation2& y,                    const Operation3& z) : op1(x), op2(y), op3(z) { }     result_type operator()(const argument_type& x) const {         return op1(op2(x), op3(x));     } }; compose2(const Operation1& op1, const Operation2& op2, const Operation3& op3) {     return binary_compose(op1, op2, op3); } //Example use: //outi == ai2 + 2ai transform(a.begin(),a.end(),out,    compose2(add< int >(),             square< int >(),             bind1st(mult< int >(),2)));

Hey guys, been a while since I posted here but then again it's been a while since I've used C++

There's a few things I don't understand about this code (taken from a university's compsci course site)

1. What functionality is being inherited from unary_function that makes it necessary to inherit binary_compose from it?
2. What are Operation2::argument_type and Operation1::result_type? I believe they are typedefs, but what are they typedefing and what purpose are they serving?
3. That "compose2" function looks like a helper function, but is it defined properly? Shouldn't it be a templated function because "Operation1, Operation2, Operation3" need to be given a type? I don't see where the types are formally being declared here...
4. If this is a function object that is supposed to compose a binary function, shouldn't operator() be defined with 2 parameters? (hence binary)

Sorry if I'm just rusty on my template understanding, I will read up on it while I wait for a response. Thanks!

[OneOffDriveByPoster]

Geminias @ Sat Oct 25, 2008 8:08 pm wrote:

1. What functionality is being inherited from unary_function that makes it necessary to inherit binary_compose from it?

See header <functional>. This provides useful typedefs for one, and a way for people to use the resulting functor through a common interface.

Geminias @ Sat Oct 25, 2008 8:08 pm wrote:

2. What are Operation2::argument_type and Operation1::result_type? I believe they are typedefs, but what are they typedefing and what purpose are they serving?

These are the typedefs provided by unary_function, binary_function and the such.

Geminias @ Sat Oct 25, 2008 8:08 pm wrote:

3. That "compose2" function looks like a helper function, but is it defined properly? Shouldn't it be a templated function because "Operation1, Operation2, Operation3" need to be given a type? I don't see where the types are formally being declared here...

The helper function is meant to use template argument deduction to help create a binary_compose object easily. The purpose is similar to make_pair(). You are correct--the declaration given does not work.

Geminias @ Sat Oct 25, 2008 8:08 pm wrote:

4. If this is a function object that is supposed to compose a binary function, shouldn't operator() be defined with 2 parameters? (hence binary)

The apparent intended use of binary_compose to create a unary function that composes a binary function with unary functions for each parameter. i.e., d(x) = c(a(x), b(x)).

Geminias @ Sat Oct 25, 2008 8:08 pm wrote:

Sorry if I'm just rusty on my template understanding, I will read up on it while I wait for a response. Thanks!

Your understanding is just fine.

[Rigby5]

I think the most important thing to remember here is that the best programming is the most obvious to understand when read.

Any code like this that is hard to understand, should not be written.

Templates in general are a real pain to debug, and therefore should be reserved for essential popular utility classes that have been carefully made bulletproof.

This code is so bad that it should never be used in a school.

[wtd]

Wrong.

That code is beautiful. Of course, C++ as currently implemented is not the best language for expressing the concepts at work here. The creation of anonymous functions can be much more elegant.

Nevertheless, mapping a function object across an aggregate data structure is a fantastic abstraction. It makes the code more declarative, and thus more readable, rather than less.

[Rigby5]

wtd @ Mon Oct 27, 2008 1:44 am wrote:

Wrong.

That code is beautiful. Of course, C++ as currently implemented is not the best language for expressing the concepts at work here. The creation of anonymous functions can be much more elegant.

Nevertheless, mapping a function object across an aggregate data structure is a fantastic abstraction. It makes the code more declarative, and thus more readable, rather than less.

No, the code is hideous.
There may be reasons or time when such concepts may be useful, but then the class, variable, and function names would have to be far more descriptive than this, not to mention comments.

[wtd]

"compose", "unary function", "bind", etc. are all immensely descriptive terms if one is familiar with the basics of functional programming.

[Rigby5]

wtd @ Wed Oct 29, 2008 10:21 pm wrote:

"compose", "unary function", "bind", etc. are all immensely descriptive terms if one is familiar with the basics of functional programming.

Those words are generalities.
They have no specific meaning.
Code must always have specific meaning and context
That is why templates are always controversial and suspect.
It is like implementing DeMorgan's theorem or the distributive principle without saying it.
It makes no sense.
Composing binary functions from unary ones or decomposing unary ones from binary functions, is not an appropriate use of templates at all.
You might as well be back to using function pointers like C
Lambda calculus is a really bad idea in my opinion.
It merely obscures the actual functionality.

[wtd]

Rigby5 @ Thu Oct 30, 2008 12:00 pm wrote:

Lambda calculus is a really bad idea in my opinion.
It merely obscures the actual functionality.

If you genuinely feel this way, then I am afraid you have no future in computer science.

[Rigby5]

wtd @ Thu Oct 30, 2008 12:47 am wrote:

Rigby5 @ Thu Oct 30, 2008 12:00 pm wrote:

Lambda calculus is a really bad idea in my opinion.
It merely obscures the actual functionality.

If you genuinely feel this way, then I am afraid you have no future in computer science.

No, you are wrong, because the most important part of programming is always readability by other humans, and doing things like overloading operators is not a clearly documented as specific functions.
This is not mathematics, where you can use shorthand notation.
You don't want to.
You want to have everything explicitly defined in an intuitive and easily searched methodology.
For example, one programmer implemented array functions like cross product and dot product by over riding operators, and it had to be all thrown out.
It was silly and no one could use it or wanted to.
There are a lot of things that are bad about C++, like multiple inheritance.
Bjarne Stroustrup put a lot of things in C++ that were not a good idea to actually use.

Believe me, millions of people are using my code, and it they always like it.
Hundreds of other programmer have no problem modifying it, over and over.
That is what makes good code.
Not implementing new operators on the fly.

If you really want to know what the future of computer science is, unfortunately it is not even C++ at all.
All they want to hire these days are C# and Java programmers.