Inconsistency between boost::bind and boost::lambda::bind
Hello everybody,
I've started to use the functional programming facilities offered
by boost, and they're really impressive.
To begin with, I've started using both; I've seen however, that
when I #include both
If you must include both, I'd suggest using the namespace alias (as I've commonly seen it: bll = boost::lambda) While I don't know of an exhaustive comparison, I do believe that boost::bind has better support for smart pointers. As to the const/non-const ref problem, try using boost::ref. HTH, Pablo Aguilar Gerardo Lamastra wrote:
Hello everybody,
I've started to use the functional programming facilities offered by boost, and they're really impressive.
To begin with, I've started using both; I've seen however, that when I #include both and I must use full namespace names to address lambda placeholders. In other words, instead of writing
<snip code>
also if I've written a using boost::lambda declaration; I know,
I can simplify this using a namespace alias, but I was trying to keep the code less clobber as I can, because it has to be used for teaching/example purposes. So, my first question would be: where could I find an exhaustive comparison between these two facilities? And, is there any indication on what to prefer, also related to future development and/or inclusion in C++ standards (If I remember well, boost::lambda has been proposed in tr1?)
The second question points at a small inconsistency that I believe I've found while doing some experiments: boost::bind and boost::lambda::bind offer similar construct, but the former works while the latter fails in the example included below.
The situation is the following: if I try to create a nullary lamnda function with boost::lambda::bind() like this:
generate_n(inserter(v, v.begin()), 10, boost::lambda::bind( boost::lambda::new_ptr(),*this) );
the compiler fails to compile: it tries to pass the this pointer as a const reference somehow, and then it fails claiming that a Slave(const Master& m) cannot be found; If I try to add one, it fails with a similar error.
If I substitute the boost::lambda::bind() with a boost::bind(), it compiles & works perfectly.
Thanks for the attention, -Gerardo Lamastra
<snip code and legal notice>
Gerardo Lamastra wrote:
So, my first question would be: where could I find an exhaustive comparison between these two facilities? And, is there any indication on what to prefer, also related to future development and/or inclusion in C++ standards (If I remember well, boost::lambda has been proposed in tr1?)
Nobody has written an exhaustive comparison between boost::bind and lambda::bind, but the general rule is to use lambda::bind if you use Lambda, boost::bind otherwise. :-) TR1 contains a 'bind' that is a superset of boost::bind. Both boost::bind and boost::lambda::bind are reasonable approximations of std::tr1::bind.
The situation is the following: if I try to create a nullary lamnda function with boost::lambda::bind() like this:
generate_n(inserter(v, v.begin()), 10, boost::lambda::bind
( boost::lambda::new_ptr<Slave>(),*this) ); the compiler fails to compile: it tries to pass the this pointer as a const reference somehow, and then it fails claiming that a Slave(const Master& m) cannot be found; If I try to add one, it fails with a similar error.
If I substitute the boost::lambda::bind() with a boost::bind(), it compiles & works perfectly.
Your code seems wrong. Remember that bind makes a copy of its arguments, '*this' in this case. So when you construct a new Slave, its reference is initialized to this internal copy of *this. The function object then disappears and the result is a dangling reference. Use boost::ref(*this). Now, if you are interested in why Lambda doesn't accept the code whereas Bind does: Lambda always makes these internal copies const. boost::bind propagates the const-ness of the function object to its members. In this case the function object is non-const and so is the internal copy of *this.
participants (3)
-
Gerardo Lamastra
-
Pablo Aguilar
-
Peter Dimov