$include_dir="/home/hyper-archives/boost/include"; include("$include_dir/msg-header.inc") ?>
From: Peter Dimov (pdimov_at_[hidden])
Date: 2002-03-08 13:54:02
From: "Jaakko Jarvi" <jajarvi_at_[hidden]>
> We chose this implementation as it treats all arguments of the bind
> expression similarly, the first argument is no exception.
Yes, agreed. It definitely makes sense.
> And it is more flexible.
In what ways?
> > The "Bind way" to evaluate the first argument is
> >
> > bind(apply<R>(), _1, _2);
> >
> > where apply(f, a1, ..., aN) returns f(a1, ..., aN). (In
> > boost/bind/apply.hpp.)
>
> Does this cover something like:
>
> int add(int a, int b) { return a+b; }
> int mul(int a, int b) { return a*b; }
>
> int(*)(int, int) add_or_mul(bool x) {
> return x ? add : mul;
> }
>
> bool condition; int i; int j;
> ...
> bind(bind(&add_or_mul, _1), _2, _3)(condition, i, j);
Yes, I think it does.
bind(apply<int>(), bind(add_or_mul, _1), _2, _3)(condition, i, j);
> > bind(foo, 1, 2) will fail. bind(foo, _1)(1, 2) will succeed. There is a
> > difference between the two; the first is a common error and is detected
(at
> > 'bind time', i.e. even without a call) but the latter is, at least in my
> > experience, usually deliberate and rarely accidental.
> I don't see much difference in the nature of the errors (if the latter
> then is an error or not).
The difference is that:
* The former is always an error.
* The former is a common programming mistake.
* The latter has a legitimate meaning (if you don't outlaw it explicitly.)
* The latter is not a common programming mistake. It's also not an uncommon
programming mistake. :-)
> In any case, as there is an easy way to achive the discarding of
> the arguments, we do not lose much flexibility with the BLL way.
So be it.