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 &),
> 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
> 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.
> Are you saying that because, in this specific case, 'bind' does not bind,
> 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
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
Boost list run by bdawes at acm.org, gregod at cs.rpi.edu, cpdaniel at pacbell.net, john at johnmaddock.co.uk