composition and arguement binding: what to use: boost::bind vsboost::mpl vs boost::lambda

newer
Re: Re: how to get regex to link...

Robert Mathews

15 Mar 2005 15 Mar '05

4:56 p.m.

I've become rather confused about the exact relationship between these libraries. In particular, boost::mpl seems to contain placeholders and lambda templates just like boost::bind and boost::lambda. That leds me to wonder if there would be any point to using boost::bind or boost::lambda if you are using boost::mpl? In fact, if boost::mpl is a functional superset of the other two libraries, why not drop those libraries from boost altogether and eliminate the confusion? Rob.

Show replies by date

Stuart Dootson

16 Mar 16 Mar

7:29 a.m.

On Tue, 15 Mar 2005 11:56:31 -0500, Robert Mathews wrote:

...

I've become rather confused about the exact relationship between these libraries. In particular, boost::mpl seems to contain placeholders and lambda templates just like boost::bind and boost::lambda.

That leds me to wonder if there would be any point to using boost::bind or boost::lambda if you are using boost::mpl? In fact, if boost::mpl is a functional superset of the other two libraries, why not drop those libraries from boost altogether and eliminate the confusion?

Rob.

boost::mpl performs binding of meta-functions (i.e. binding within the compile-time domain), whereas bind and lambda perform binding of functions and function objects (i.e. binding within the run-time domain). As far as I can see, Boost.Bind is effectively a subset of Boost.Lambda (I may well be wrong, though!). However, if you're using an older compiler (such as MSVC6), then using Boost.Lambda can be problematic, whereas Boost.Bind works fine. HTH Stuart Dootson

David Abrahams

2:41 p.m.

Stuart Dootson writes:

...

On Tue, 15 Mar 2005 11:56:31 -0500, Robert Mathews wrote:

...
I've become rather confused about the exact relationship between these libraries. In particular, boost::mpl seems to contain placeholders and lambda templates just like boost::bind and boost::lambda.

That leds me to wonder if there would be any point to using boost::bind or boost::lambda if you are using boost::mpl? In fact, if boost::mpl is a functional superset of the other two libraries, why not drop those libraries from boost altogether and eliminate the confusion?

Rob.

boost::mpl performs binding of meta-functions (i.e. binding within the compile-time domain), whereas bind and lambda perform binding of functions and function objects (i.e. binding within the run-time domain).

As far as I can see, Boost.Bind is effectively a subset of Boost.Lambda (I may well be wrong, though!). However, if you're using an older compiler (such as MSVC6), then using Boost.Lambda can be problematic, whereas Boost.Bind works fine.

And unless Boost.Lambda has been updated since I looked, there are some nice things that Boost.Bind handles automatically, like calling through smart pointers, that aren't quite so easy with Boost.Lambda. -- Dave Abrahams Boost Consulting www.boost-consulting.com

Kevin Wheatley

17 Mar 17 Mar

9:59 a.m.

New subject: composition and arguement binding: what to use:boost::bind vsboost::mpl vs boost::lambda

David Abrahams wrote:

...

And unless Boost.Lambda has been updated since I looked, there are some nice things that Boost.Bind handles automatically, like calling through smart pointers, that aren't quite so easy with Boost.Lambda.

I tried recently to use containers of smart pointers (boost::shared_ptr) and ran into a real mess of error messages (VC++ 7.1), even though I was doing a 'simple' std::find_if() with a _1 == value test. When I had simple pointers Boost.Lambda worked nice and cleanly, but switching to shared_ptr, was almost impossible to work out what was going on, I simply switched to a few composed boost::bind()s and it worked first time, so I have to agree here that Boost.Bind wins out on this simple use, even though it looses the nice syntax of Boost.Lambda. Subsequently, the containers now contain std::pair's to shared_ptrs, so I have even more composition going on, which for a one off 'function' is getting messy, with Lambda it should be much simpler so I'd certainly like to know if I missed something with this. Kevin -- | Kevin Wheatley, Cinesite (Europe) Ltd | Nobody thinks this | | Senior Technology | My employer for certain | | And Network Systems Architect | Not even myself |

Peter Dimov

10:55 a.m.

New subject: composition and arguement binding: what to use:boost::bind vsboost::mpl vs boost::lambda

Kevin Wheatley wrote:

...

Subsequently, the containers now contain std::pair's to shared_ptrs, so I have even more composition going on, which for a one off 'function' is getting messy, with Lambda it should be much simpler so I'd certainly like to know if I missed something with this.

Extracting a member of a pair is equally painful with Bind and Lambda: bind(&Pair::second, _1). Lambda also supports _1->*&Pair::second for ordinary pointers, but not for shared_ptr, where you'll need something like &*_1->*&Pair::second. The current CVS bind now supports !bind(...) bind(...) == value bind(...) == _1 bind(...) == bind(...) and similarly for !=, <, <=, >, >=. You may be able to avoid some of the compositions. Other notable differences between Bind and the bind subset of Lambda are the number of supported placeholders and support for function<>::contains. They also differ in their handling of the first argument when it's a nested lambda/bind expression or a placeholder; Lambda can do bind( _1, _2 ), Bind cannot. Bind also respects its const qualifier so that when a non-const bind( f, 1 ) is called, the non-const operator() of f is called and it can mutate the stored copy of 1. Most of these are of no concern for ordinary use. Well, maybe except for cool examples: #include #include <algorithm> #include <iostream> #include <iterator> int next( int & x ) { return ++x; } int main() { std::generate_n( std::ostream_iterator<int>( std::cout, " " ), 8, boost::bind( next, 0 ) ); }

Kevin Wheatley

3:10 p.m.

New subject: composition and arguement binding: what touse:boost::bind vsboost::mpl vs boost::lambda

Peter Dimov wrote:

...

Kevin Wheatley wrote:

...
Subsequently, the containers now contain std::pair's to shared_ptrs, so I have even more composition going on, which for a one off 'function' is getting messy, with Lambda it should be much simpler so I'd certainly like to know if I missed something with this.

Extracting a member of a pair is equally painful with Bind and Lambda: bind(&Pair::second, _1). Lambda also supports _1->*&Pair::second for ordinary pointers, but not for shared_ptr, where you'll need something like &*_1->*&Pair::second.

Peter, Thanks for the reply. It's all starting to look rather like Perl at this point and as such my inbuild parser is failing to parse what that does at a glance (can't work out what set of rules I've got to use :-), so it might be worth avoiding just so that mortals can simply see what is going on! I guess if Lambda understood about smart pointers in a similar way to Bind some of this syntax could be simplfied. see attatched for what I'd like to do. Kevin -- | Kevin Wheatley, Cinesite (Europe) Ltd | Nobody thinks this | | Senior Technology | My employer for certain | | And Network Systems Architect | Not even myself | #include <vector> #include <algorithm> #include <iostream> #include <cstddef> #include #include #include // So don't do this in real code it is not stylish using boost::shared_ptr; using namespace boost::lambda; using namespace std; int main(int /*argc*/, char** /*argv*/) { const int numberValues = 10; vector<int> vi(numberValues); for_each(vi.begin(), vi.end(), _1 = 1); // Assign the value 1 to all vi[numberValues / 2] = -1; vector vpi(numberValues); transform(vi.begin(), vi.end(), vpi.begin(), &_1); // Assign the addresses to the pointers for_each(vpi.begin(), vpi.end(), cout << _1 << constant(' ') << *_1 << constant('\n')); vector vspi(numberValues); for (size_t i = 0; i != vspi.size(); ++i) // Fill with a sequence of new integers [0..numberValues] vspi[i].reset(new int(i)); // N.B. Can't use boost::lambda::bind with operator new() // Ignore the unsigned mismatch warning. for_each(vspi.begin(), vspi.end(), cout << bind(&shared_ptr<int>::get, _1) << constant(' ') << *bind(&shared_ptr<int>::get, _1) << constant('\n')); for_each(vspi.begin(), vspi.end(), cout << _1 << constant(' ') << *_1 << constant('\n')); // Fails here return 0; }

Robert Mathews

2:48 p.m.

New subject: composition and arguement binding: what to use:boost::bind vsboost::mpl vs boost::lambda

"Kevin Wheatley" wrote in message news:4239550C.B3B82BE0@cinesite.co.uk...

...

David Abrahams wrote:

...
And unless Boost.Lambda has been updated since I looked, there are some nice things that Boost.Bind handles automatically, like calling through smart pointers, that aren't quite so easy with Boost.Lambda.

I tried recently to use containers of smart pointers (boost::shared_ptr) and ran into a real mess of error messages (VC++ 7.1), even though I was doing a 'simple' std::find_if() with a _1 == value test.

...

When I had simple pointers Boost.Lambda worked nice and cleanly, but switching to shared_ptr, was almost impossible to work out what was going on, I simply switched to a few composed boost::bind()s and it worked first time, so I have to agree here that Boost.Bind wins out on this simple use, even though it looses the nice syntax of Boost.Lambda.

FWIW, my mileage with Boost.Lambda was much the same - the simple cases worked fine, but anything with smart pointers didn't work well. On other hand, I found that boost::bind worked simply and cleanly, and was a vast improvement over the stl memfun/memfun1/etc family of functions. (I'm also using VC++ 7.1)

...

Subsequently, the containers now contain std::pair's to shared_ptrs, so I have even more composition going on, which for a one off 'function' is getting messy, with Lambda it should be much simpler so I'd certainly like to know if I missed something with this.

Kevin

-- | Kevin Wheatley, Cinesite (Europe) Ltd | Nobody thinks this | | Senior Technology | My employer for certain | | And Network Systems Architect | Not even myself |

7183

Age (days ago)

7185

Last active (days ago)

List overview

Download

6 comments

5 participants

participants (5)

David Abrahams
Kevin Wheatley
Peter Dimov
Robert Mathews
Stuart Dootson