Re: [boost] [Review] bind

From: Mark Rodgers (mark.rodgers_at_[hidden])
Date: 2001-08-17 15:43:46

> > > 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?

We could take just those templates which overlap and place them into a
separate header included by functional.hpp and mem_fun.hpp.

> 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.

Yes, you are correct.  In fact I used call_traits to avoid an extra copy
when passing by value.  My mistake.

> > so why not only allow the latter form?
>
> Not pay for what you don't use?

Well, I strongly suspect that only the zero and one argument forms of your
mem_fun will ever get used directly - all other uses will be via bind when
a member function with more arguments will be reduced to something that can
be used with a standard algorithm.  If this is true then exposing mem_fun
provides no benefit *except* for smart pointer types, when an extension to
mem_fun is indeed useful.

> 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.

Agreed.

> 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.

Yes, but where you write

   bind( &X::f, _1, _2 )

what you really want (I believe) to write is

   _1->f( _2 )

and it's just that you can't do this.  I think the name should reflect what
you are really trying to do - call a function.  "bind" is a complete
misnomer.
Sometimes I use my hammer to extract nails.  Does that mean I should really
call it a "nail extracter"?

> 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. :-)

No because actually I want this library to be included.  I already have a
set of templates I use like this:

void CompositeObject::f( int i, double d, const string &s )
{
    std::for_each( m_elements.begin(), m_elements.end(),
                   call( &Object::f, i, d, s ) );
}

I see an opportunity to replace these with "bind", but preferably under a
new name.

Mark