"Matthias Kaeppler" <nospam@digitalraid.com> wrote in message news:d0h8mf$v50$1@sea.gmane.org... | Thorsten Ottosen wrote: | > Hi Matthias, | > | > I have been playing with similar functionality for Boost.Pointer Container | > because the ptr_set class needs it. | > | > I have a question, though. I'm thinking, what is the benefit of your approach | > compared to | > | > template< class Fun > | > class indirect_fun | > { | > Fun fun; | > public: | > typedef typename result_of<Fun>::type result; | > | > indirect_fun( Fun f ) : fun(f) | > { } | > | > template< class T > | > result operator( T* r ) const | > { return fun( *r ); } | > | > template< class T, class U > | > result operator( T* r, U* r2 ) const | > { return fun( *r, *r2 ); } | > | > // etc | > }; | There are several problems with this template. | | First, it's not an "Adaptable Binary Function" or "Adaptable Unary | Function", because it fails to provide the required typedefs result_type | and argument_type, and result_type and first_argument_type, | second_argument_type respectively. yes, that is true. | Second, it might fail to compile when Fun takes arguments by reference. | I had problems at this part, that's why I used the boost type traits | library to remove any references on the type first, and only work on | "raw" const-pointers. well, that doesn't happen when operator()() is templated. | Third, (correct me if I'm wrong, I haven't used it before), as far as I | understand, the result_of class template won't work if you instantiate | your template with a plain function. yep, it should be funtion_traits<Fun>::result_type; but my question is this: given that these typedefs are added to the template, what is the benefit of having 2 classes instead of 1? -Thorsten