Re: [boost] [Review] bind

From: Peter Dimov (pdimov_at_[hidden])
Date: 2001-08-18 09:48:24

From: "John Maddock" <John_Maddock_at_[hidden]>
> >The two libraries will then coexist as long as mem_fun.hpp is included
> >before functional.hpp.
>
> Doesn't that introduce potential ODR violations?

Yes it does, I retract this suggestion. :-)

> In any case is your version a true replacement for the version in
> <boost/functional.hpp> - for example does it fix the reference to
reference
> problem?

Yes, it is intended to be a replacement for std::mem_fun (and boost::mem_fun
from functional.hpp); it doesn't suffer from the reference to reference
problem.

It is not a "true" replacement since the return type is not the same, but I
think that relying on the return type of mem_fun is extremely rare. In fact,
I think that specifying the exact return type of std::mem_fun overconstrains
the implementation.

> I'd like to see your version either removed or integrated with
> <boost/functional.hpp>, sorry :-(

Removed is fine by me.

> >is a useful generalization that will become more frequent when shared_ptr
> >moves into std.
>
> Making mem_fun work with a shared pointer is nice, but is it really a
> killer feature?  Users can just as easily pass "my_shared_ptr.get()"
rather
> than "my_shared_ptr" into this, and since these are generally used as
> temporaries there is no lifetime management issue here iether IMO.

I'm not sure that I follow.

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

How can users pass my_shared_ptr.get() into this?

Also, mem_fun is extensible - it can be made to support any smart pointer,
not just shared_ptr.

--
Peter Dimov
Multi Media Ltd.