Re: [boost] functional.hpp and mem_fun.hpp (was [Review] bind)

From: Mark Rodgers (mark.rodgers_at_[hidden])
Date: 2001-08-28 13:28:08

> However, std::mem_fun1_t takes its parameter by value. This means that it
> works for types with destructive copy semantics, whereas your version does
> not. This means that boost::mem_fun does not conform.

It was never the intention to make a standard conforming implementation
of mem_fun - there are plenty of those around.  The idea was to take the
mem_fun idea and improve it.

> I can't use call_traits; using call_traits changes the semantics of the
call
> thanks to that wonderful invention called std::auto_ptr. ;-) The interface
> should not specify optimizations, only behavior.

This can be easily fixed if call_traits were to be partially specialised
for auto_ptr to use pass by value.  That's probably not a bad idea.

>
> > In fact I think it has a negative
> > impact so this would be my first choice if I didn't think I'd
> > already lost that battle.
>
> This is a more interesting statement. What is the negative impact of
mem_fn?

The problem with your bind/mem_fn is that it perpetuates obsolete ideas in
which
users have to remember obscure rules.  We should be able to get away from
the
idea that programmers need to be aware of "binding".

ETs give us the chance to do better.

Put it this way, with ET's we'd expect to be able to write

  (_1 + _2)(1234, 4567);

as well as

  (_1 + 4567)(1234);

and

  (1234 + _1)(4567);

Note two things here (at the risk of teaching you to suck eggs!):

1. We don't have to use bind in some fashion for the last two:

     bind( (_1 + _2), _1, 4567 )( 1234 ); // Not!

   The same syntax is used whether we choose to bind an argument or not.

2. The syntax for creating a function object reflects what happens when
   we apply the function object.  We have created something that calls
   operator+ with an operator+ and not some "create_plus" function.
   You could call ETs "function objects by example".

I don't see why the same shouldn't apply with function calls.

To satisfy (1), your bind should *always* be used and your mem_fun should be
hidden from the user.

To satisfy (2) (and given that we can't actually use the function call
syntax), bind should be called apply or something similar, i.e. a name that
reflects what happens when the resulting function object is used.

Mark