[lambda] helping lambda to deduce return type and then avoid 'ret<T>'
Hi, the lambda manual says: "The return type deduction system may not be able to deduce the return types of some user defined operators or bind expressions with class objects. A special lambda expression type is provided for stating the return type explicitly and overriding the deduction system. To state that the return type of the lambda functor defined by the lambda expression e is T, you can write:" and indeed for even very simple arithmetic user-defined classes (for example boost.units quantities) the lambda expression is poluted with many many ret<T> statements, for example _1*_1/(_1+x)/(_1-x) becomes ret<anothertype>(ret<usertype>(_1*_1)/ ret<othertype>(ret<usertype>(_1+x)/ret<usertype>(_1-x))); the question is, is there a way to help lambda library to help deducing the return type to avoid the repeated use of ret<T>. Thank you, Alfredo
and indeed for even very simple arithmetic user-defined classes (for example boost.units quantities) the lambda expression is poluted with many many ret<T> statements, for example
_1*_1/(_1+x)/(_1-x)
becomes
ret<anothertype>(ret<usertype>(_1*_1)/ ret<othertype>(ret<usertype>(_1+x)/ret<usertype>(_1-x)));
the question is, is there a way to help lambda library to help deducing the return type to avoid the repeated use of ret<T>.
You should take a look at <boost/units/lambda.hpp> - Torsten Maehne contributed it to deal with interplay between lambda and units... Something similar might be worthwhile with interval as well. Matthias
On Mon, May 24, 2010 at 2:51 PM, Matthias Schabel <boost@schabel-family.org> wrote:
and indeed for even very simple arithmetic user-defined classes (for example boost.units quantities) the lambda expression is poluted with many many ret<T> statements, for example
_1*_1/(_1+x)/(_1-x)
becomes
ret<anothertype>(ret<usertype>(_1*_1)/ ret<othertype>(ret<usertype>(_1+x)/ret<usertype>(_1-x)));
the question is, is there a way to help lambda library to help deducing the return type to avoid the repeated use of ret<T>.
You should take a look at <boost/units/lambda.hpp> - Torsten Maehne contributed it to deal with interplay between lambda and units... Something similar might be worthwhile with interval as well.
Or Boost.Phoenix, it handles such things better.
On May 24, 5:05 pm, OvermindDL1 <overmind...@gmail.com> wrote:
On Mon, May 24, 2010 at 2:51 PM, Matthias Schabel
You should take a look at <boost/units/lambda.hpp> - Torsten Maehne contributed it to deal with interplay betweenlambdaandunits... Something similar might be worthwhile with interval as well.
or Boost.Phoenix, it handles such things better.
OvermindDL1, you are right, while lambda with units needs to explicitly to #include<boost/units/ lambda.hpp> boost phoenix works out of the box cout<< (boost::lambda::_1+boost::lambda::_1)(energy) <<endl; // needs #include "boost/units/lambda.hpp" cout<< (boost::phoenix::arg_names::arg1 + boost::phoenix::arg_names::arg1)(energy) <<endl;
On 5/29/10 8:50 AM, alfC wrote:
On May 24, 5:05 pm, OvermindDL1<overmind...@gmail.com> wrote:
On Mon, May 24, 2010 at 2:51 PM, Matthias Schabel
You should take a look at<boost/units/lambda.hpp> - Torsten Maehne contributed it to deal with interplay betweenlambdaandunits... Something similar might be worthwhile with interval as well.
or Boost.Phoenix, it handles such things better.
OvermindDL1, you are right, while lambda with units needs to explicitly to #include<boost/units/ lambda.hpp> boost phoenix works out of the box
cout<< (boost::lambda::_1+boost::lambda::_1)(energy)<<endl; // needs #include "boost/units/lambda.hpp" cout<< (boost::phoenix::arg_names::arg1 + boost::phoenix::arg_names::arg1)(energy)<<endl;
Glad to hear. Anyway, it'll get even better. Right now, we're in the development stage of Phoenix-3 using proto. As you know, Phoenix-3 will be the next lambda. Boost-lambda will still be available, but will be in maintenance mode (and for backward compatibility) as soon as we get Phoenix-3 in the distribution. Regards, -- Joel de Guzman http://www.boostpro.com http://spirit.sf.net
while lambda with units needs to explicitly to #include<boost/units/ lambda.hpp> boost phoenix works out of the box Glad to hear. Anyway, it'll get even better. Right now, we're in the development stage of Phoenix-3 using proto. As you know, Phoenix-3 will be the next lambda. Boost-lambda will still be available, but will be in maintenance mode (and for backward compatibility) as soon as we get Phoenix-3 in the distribution.
will it be a new implementation with the same interface? same syntax? (I am worried of changes in the syntax for Phoenix-3), I am sure this was asked before: when will it be available in Boost? Thank you, Alfredo
On 5/29/2010 1:32 PM, alfC wrote:
while lambda with units needs to explicitly to #include<boost/units/ lambda.hpp> boost phoenix works out of the box Glad to hear. Anyway, it'll get even better. Right now, we're in the development stage of Phoenix-3 using proto. As you know, Phoenix-3 will be the next lambda. Boost-lambda will still be available, but will be in maintenance mode (and for backward compatibility) as soon as we get Phoenix-3 in the distribution.
will it be a new implementation with the same interface? same syntax?
As much as we can, yes. But we can't promise 100%. The extension mechanism and of course the undocumented features will mostly be changed.
(I am worried of changes in the syntax for Phoenix-3), I am sure this was asked before: when will it be available in Boost?
All I can say is ASAP. There is a Google GSOC project on this, so there's a good chance that we'll have something significant, if not finished, after summer. That said, I can make no promises. Regards, -- Joel de Guzman http://www.boostpro.com http://spirit.sf.net http://www.facebook.com/djowel Meet me at BoostCon http://www.boostcon.com/home http://www.facebook.com/boostcon
participants (4)
-
alfC -
Joel de Guzman -
Matthias Schabel -
OvermindDL1