Re: [boost] [Review] bind

From: Peter Dimov (pdimov_at_[hidden])
Date: 2001-08-17 13:55:18

From: "Mark Rodgers" <mark.rodgers_at_[hidden]>
> Firstly, the name mem_fun has definitely got to change.  It
> conflicts with the existing mem_fun in boost/functional.hpp.

I wanted to hear your opinion on this.

The name 'mem_fun' is intentional. boost::mem_fun (from mem_fun.hpp) is
intended to be a replacement for std::mem_fun.

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.

> Of course this begs the question - could the two mem_funs
> be amalgamated so that perhaps functional.hpp could just
> include mem_fun.hpp?  Unfortunately not.  The two are
> fundamentally different - the existing mem_fun creates an
> adaptable unary function object; Peter's function object is
> not adaptable and cannot be made to be adaptable.

From mem_fun.html:

"All function objects returned by mem_fun expose a return_type typedef that
represents the return type of the member function. In addition, the zero-
and one- argument variants expose first_argument_type and
second_argument_type for compatibility with std::mem_fun. Of course, it is
not possible to fully describe the first argument type of the
mem_fun-generated function objects with a simple typedef."

(return_type should be result_type, of course. This will be fixed.)

So existing code should continue to work with mem_fun, unless I overlooked
something (else.)

> Secondly, I don't think the name bind is appropriate.  This
> suggests too close a link to the standard binders, and thus
> that Peter's bind is a function object adapter.

Again, intentional naming that reflects bind's purpose: to replace
std::bind1st and std::bind2nd.

> In fact,
> this new submission is the beginnings of an expression
> template library, and the name should reflect that.

The Lambda library uses 'bind.' :-)

> My only other concern is that, since this is the beginnings
> of an ET library, how does that affect the lambda library?

Actually Bind is not intended to be a part of an expression template library
(in its current form) although I tried to specify an interface that is
close, or equivalent, to what an ET 'bind' would provide.

Bind is intended to

* work now on a variety of compilers (inlcuding MSVC);
* provide a lightweight alternative in case a full-blown lambda library
(that I hope will be submitted for standardization) is rejected by the LWG.

Whenever Lambda, or some other ET library, finally arrives, it will bring
its own 'bind.' The two will rarely conflict, since if your compiler handles
Lambda, you would never bother with Bind, would you? :-)

--
Peter Dimov
Multi Media Ltd.