Boost logo

Boost :

From: Daniel Walker (daniel.j.walker_at_[hidden])
Date: 2007-04-28 14:24:51

On 4/28/07, Peter Dimov <pdimov_at_[hidden]> wrote:
> Daniel Walker wrote:
> > So, you mean that Bind is definitely going to overload the relational
> > operators.
> Bind already overloads the relational operators:

Aha, that was the source of my confusion. I'm not so worried about
bind(f, _1) < x. This already works even when the lambda header is
included. Moving forward, I think breaking this code can be avoided.

I'm worried about bind(f, _1 < x) or bind(f, _1) < _2.

> in more limited contexts. It is trivial to extend this overloading to work
> on expressions that involve no bind calls such as _1 == 5, _1 > _2 or !_4 -
> provided that the placeholders aren't inline functions, of course. :-)

It's also trivial to make lambda generate is_bind_expression
specialized functors. I think one or the other of the libraries should
take care of this use-case but not both, just to avoid the head aches.
But again, if one of the libraries provided a hold function to claim
the placeholder it could resolve the problem.

> > Is that also under consideration by the standard committee?
> Not yet.

Then this is TR1++. ;-) Which is fine by me, actually. I would like to
have a one-stop-shop for all my on-fly, unnamed-function-creation
needs. But I don't want to wait 10 years for it. The past decade of
dealing with bind/lambda incompatibility has been irritating enough. I
think just making lambda work with the new standard will go along way
toward alleviating these inconveniences. In the long run, it would be
nice if lambda and bind were folded together though.

> > Why not bring all the operators into bind and remove (or at
> > least largely remove) the need for a separate lambda library to
> > support lambda expressions?
> The operators that Bind currently supports do not require return type
> deduction since their return type is assumed to be bool.

That makes sense.


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