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
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
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
> 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()"
> 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.
Boost list run by bdawes at acm.org, gregod at cs.rpi.edu, cpdaniel at pacbell.net, john at johnmaddock.co.uk