Re: [boost] functional.hpp and mem_fun.hpp

From: Mark Rodgers (mark.rodgers_at_[hidden])
Date: 2001-08-31 14:35:21

From: "Peter Dimov" <pdimov_at_[hidden]>
> 
> Mark Rodgers:
> 
> "Firstly, the name mem_fun has definitely got to change.  It
> conflicts with the existing mem_fun in boost/functional.hpp.
> Of course this begs the question - could the two mem_funs
> be amalgamated so that perhaps functional.hpp could just
> include mem_fun.hpp?  Unfortunately not.  The two are
> fundamentally different - the existing mem_fun creates an
> adaptable unary function object; Peter's function object is
> not adaptable and cannot be made to be adaptable."

Yes, well you proved me wrong about the incompatibility and 
alleviated my other concerns about compilers and compile times.

I think there is pretty widespread agreement that adding your
mem_f(u)n under a new name is A Bad Thing so it seems we have
three choices:

1. We amalgamate (functional.hpp includes mem_fun.hpp) and 
   you change to use call_traits as functional.hpp does at 
   the moment.  Optionally call_traits changes to address 
   your concerns about auto_ptr.

2. We amalgamate but we use pass by value as you do now,
   thus changing behaviour for existing users of functional.hpp.

3. We hide your mem_fun as an implementation detail of bind
   since bind provides a superset of the functionality.

I think we've made our relative positions clear.  To spell it
out, I favour (3) or (1) in that order.  I'm very opposed to (2)
but if there is consensus that it is best, I'll go along with it.

Since we don't seem to be be able to reach agreement between
ourselves, I suggest we call for votes.  I am particularly
interested to hear from users of functional.hpp (if there are
any besides me!) on their views of (2).

I'd also be interested in a coherent argument against (3) since
I'm obviously missing.  IMHO it seems by far the best solution 
and yet no-one else seems to like it.

Mark