Re: [boost] [Review] bind

From: Greg Colvin (gcolvin_at_[hidden])
Date: 2001-08-17 16:19:01

From: "Peter Dimov" <pdimov_at_[hidden]>
> 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.)

Wouldn't std::mem_fun be a different function that boost::mem_fun?

If so, where is the conflict?

> > 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.
> 
> 
> Info: http://www.boost.org  Unsubscribe: <mailto:boost-unsubscribe_at_[hidden]> 
> 
> Your use of Yahoo! Groups is subject to http://docs.yahoo.com/info/terms/ 
> 
> 
>