|
Boost : |
From: Peter Dimov (pdimov_at_[hidden])
Date: 2002-04-10 06:37:23
From: "Beman Dawes" <bdawes_at_[hidden]>
> At 11:08 AM 4/9/2002, Terence Wilson wrote:
>
> >LOL, I'm sure Peter gets weary of answering this one- I asked it a
> >while ago. What are the chances of boost::bind being accepted to
> >the standard along with shared_ptr etc? The answer is probably
> >arcane, but can someone provide rough answer? I hope it goes
> >mainstream soon.
>
> IMO, A lot depends on Boost developers being able to present the
> standards committee with a coherent roadmap to take us from the current
> standard to a better world with much easier to use function objects.
Just my personal opinion, but if we wait for a roadmap, we'll never get a
std::bind, no matter whether standalone or a part of a bigger whole.
My suggestion is to add boost::bind (and boost::function, 'cause the two
combined are more than a sum of the parts) in the current "package" of
libraries for consideration. Let the committee know about Lambda, but allow
them the option to reject the big picture without necessarily rejecting
bind.
I (user hat on) do want to get a standard lambda library, but at the same
time, I'll settle for a standard bind if this is the only thing that has a
chance to pass through the committee.
> I'm worried we will just confuse the committee (translation: I'm a bit
> confused myself) if we just present parts of the puzzle like bind
> without having a roadmap showing the steps to a complete solution.
My (limited) experience so far is that it's not _that_ easy to confuse the
committee. ;-)
Seriously, I've made every attempt to make the bind specification "open" and
aware of the big picture, as I see it.
To make bind play with lambda expressions, the only change necessary is from
x(v1, v2, ..., vm) when x is (a copy of) a function object returned by bind
( see http://www.boost.org/libs/bind/bind.html#CommonDefinitions )
to
x(v1, v2, ..., vm) when x is (a copy of) a function object returned by the
lambda library.
Boost list run by bdawes at acm.org, gregod at cs.rpi.edu, cpdaniel at pacbell.net, john at johnmaddock.co.uk