Re: [boost] [Review] bind

From: Peter Dimov (pdimov_at_[hidden])
Date: 2001-08-17 15:12:50

From: "Mark Rodgers" <mark.rodgers_at_[hidden]>
> From: "Peter Dimov" <pdimov_at_[hidden]>
> > To fix the conflict between functional.hpp and mem_fun.hpp, I propose
that
> > the functional.hpp definition of mem_fun be surrounded by
> >
> > #ifndef BOOST_MEM_FUN_HPP_INCLUDED
> > #endif
> >
> > The two libraries will then coexist as long as mem_fun.hpp is included
> > before functional.hpp.
>
> I am absolutely opposed to this idea.

Not good. Do you have a better idea? Assuming that mem_fun.hpp is accepted
into boost, my other option (it's my responsibility to make mem_fun.hpp
work - somehow -even in the presence of functional.hpp) is to provide a
mechanism for users to rename mem_fun to something else, like mem_fun2 (via
a macro.)

> The order of includes should
> not matter.  If anything, functional.hpp would include mem_fun.hpp.

Existing functional.hpp users would probably not like this.

> However that includes a lot of extra baggage, and also your mem_fun1_t
> replacement doesn't use call_traits so I suspect suffers from the
> reference-to-reference problem.

I think that it does not. For a member function int (X::*) (int, int &), it
will take the second argument by value and the third by reference.

> Of course that can be fixed, but then we have compiler compatibility
> issues, compile time issus and anyway I still have to question the need
for
> a new mem_fun.

Do others agree?

> It seems that if anything, it should be an implementation
> detail.  As far as I can make out
>
>      mem_fun( &X::foo )( x, 123 );
> and
>      bind( &X::foo, _1, _2 )( x, 123 )
>
> are equivalent,

Not exactly equivalent, but close.

> so why not only allow the latter form?

Not pay for what you don't use?

Assume that bind.hpp is submitted for inclusion in the standard library but
is rejected; do you still feel that mem_fun should not be proposed at all?

void k(std::vector<boost::shared_ptr<X> > const & v)
{
    std::for_each(v.begin(), v.end(), boost::mem_fun(&X::f));
};

is a useful generalization that will become more frequent when shared_ptr
moves into std.

To put it another way, if this were a review for mem_fun.hpp, without any
mention of bind, how would you vote? Reject it because it's useless?

> And I repeat,
> given that the latter doesn't actually bind anything, why call it bind?

Are you saying that because, in this specific case, 'bind' does not bind, it
doesn't deserve the name? There are many other cases where it does bind.

Overall, I think that you should simply vote for rejection. I don't have a
problem with that. In fact it's about time for Boost to reject something
just to set a precedent, or it will grow uncontrollably. :-)

--
Peter Dimov
Multi Media Ltd.