Boost logo

Boost :

From: jaakko.jarvi_at_[hidden]
Date: 2001-08-20 03:47:23

Hi Peter and others,

Sorry for commenting so late in the process, it's already past 19th,
as the review period is not officially declared to be over, I hope I'm
still on time.

Like Peter said, bind is kind of a partial solution while waiting for
more full-fledged expression template library.
The LL has been sitting in the vault for quite some time, but it will
be submitted, sooner rather than later, so I want to make sure that
the two libraries
(bind and LL) are not conflicting in their functionalities.

First, bind offers a subset of the functionalities of LL (except for
the visitor stuff). So in theory,
if LL is at some point accepted to boost, users could just throw in a
include file and things should work. Currently this is not so.
There is a major difference between how arguments are stored within
bound function.
I'm placing a full article about this issue in the Files section
(directory: lambda, file: The paper appeared in the
proceedings of the MPOOL'01 workshop

In short, the issue is this:

C++ functions can take their arguments as copies or as references.
In an ideal case, a binding library should just replicate the
prototype of
the underlying function, so that bound arguments that the function
takes as references should be stored as references, and bound
that the function takes as copies, should be stored as copies.
This is not possible to implement staying inside the
current language.

The bind library has taken the route to store the bound arguments as
except when ref or cref is used, whereas LL tries to make an educated
whether to store the arguments as references or as copies.

Here's an example taken from the article:

class turtle {
  void move(const step& s);

turtle t;
list<step> s;

for_each(s.begin(), s.end(), bind(t, _1));
// In LL moves turtle t the steps in the list of steps s
// In Peter's bind library moves a copy of turtle t

ref(t) can be used (in both libraries) to make bind store arguments by
reference, the question is just what should be the default.
Please take a look at the article for a more in-depth treatment.

I'm not saying that bind library should be changed to have the same
than LL. I'm saying that they should both have the same semantics,
and LL can be changed just as well.
I think that this is a deeper issue, and requires careful
consideration and
it should be discussed before committing us into any one solution.

Other comments

I see ref and cref are in the bind library now. What was decided on
Tuples were lifted to boost namespace, and so ref and cref are now in
and in bind libraries?!
Would 'utility' be a better place for this piece of functionality?

There was a comment on the name bind, and someone considered it bad as
e.g. bind(f, _1, _2) doesn't bind anything. Well, it does, namely the
function f. Anyway, I too chose the name bind in the old binder
(predecessor of LL) for the analogy to bind1st and bind2nd,
and I think the name is ok.

_1, _2, ... After seeing these names in Peter's library, we adopted
in LL as well. They are short, and kind of nice. They do require you
know the library to understand the code though, but I guess any other
doesn't help in this respect either.

The implementation uses a list template of its own, and that's quite a
of code. Would tuples do?

Someone asked this same question: why return_type instead of
Isn't result_type the standard name for adaptable functors? In this
 the user could write say bind(plus<int>(), _1, _2) instead of
bind<int>(plus<int>(), _1, _2).

In general, I think bind library is a good temporary solution, I hope
we will
eventually go to a full expression template library (LL :),
offering recursive binding, and binding of operator functions as well,
and free mixing of these.

So I vote for accept, but not until the argument passing/storing
has been discussed more and a clear stand has been taken.

Cheers, Jaakko

Boost list run by bdawes at, gregod at, cpdaniel at, john at