
on Tue Mar 20 2007, "Daniel Walker" <daniel.j.walker-AT-gmail.com> wrote:
Hello,
Section 3.2.3 of the Boost Parameter Library documentation prescribes a remedy for lazy binding ArgumentPacks directly using the Boost Lambda Library. I encountered some compilation errors when attempting this.
Interesting; that example passed our automated tests.
The problem is that both parameter::keyword and the lambda expression have overloads of operator||. Since using lambda expressions in conjunction with parameter::keywords is an intended use case for Boost.Parameter, why not resolve the problem by providing an operator|| specifically for this case?
template <class Tag, class Default> aux::lazy_default<Tag, lambda::lambda_functor<Default> > operator||(keyword<Tag> const& key, lambda::lambda_functor<Default> const& default_) { return key.operator||(default_); }
The attached patch implements this. Apply with 'patch -p0 < djw_lazy_binding.patch' from the boost root directory.
Seems like a good idea. Please submit this to the SF patch tracker.
However, after the patch is applied the following errors occur.
$ g++ -I./boost lazy_binding_errors.cpp 2>&1 | perl gSTLFilt.pl ... lazy_binding_errors.cpp:24: error: conversion from 'void' to non-scalar type 'string' requested
./boost/boost/parameter/aux_/arg_list.hpp:136: error: return-statement with a value, in function returning 'void' ... $
These errors happen because lazy binding ultimately depends on boost::result_of to deduce the type of the lambda expression, but boost::result_of doesn't handle lambda expressions. This issue can be resolved by applying the two patches I submitted previously.
mpl patch: http://tinyurl.com/35x5z5 utility patch: http://tinyurl.com/2h3g7n
Please submit those to the tracker, too.
These patches do not need to be applied in any particular order. Applying all three has the effect of making lazy binding behave more like the description in the documentation. I ran the Boost Parameter Library test suite and everything passed. Let me know if I've misunderstood something or if there's a better way to solve this problem or if you'd like additional documentation/tests.
I don't have any suggestions, though maybe Daniel W. does. -- Dave Abrahams Boost Consulting www.boost-consulting.com