[boost] Re: indirecter_unary, indirecter_binary

From: Thorsten Ottosen (nesotto_at_[hidden])
Date: 2005-03-07 06:27:09

"Matthias Kaeppler" <nospam_at_[hidden]> wrote in message 
news:d0h8mf$v50$1_at_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