
,prior<long_<8> > >" is illegal; the expression must be "times<typename next<int_<4> >::type,typename
I remember a thread that ran for a while on this topic, and I need to make sure I've wrapped my head around it correctly. Here are my takes on laziness: <take id="point-1"> A metafunction returns lazily if it can be used interchangeably with its return type. Numeric metatypes such as integral_c are examples of metafunctions that return lazily, e.g. "int_<6>" is the same as "typename int_<6>::type". Metafunctions such as next/prior, however, do not return lazily because they cannot be used interchangeably with their return types. For example, "times<next<int_<4> prior<long_<8> >::type>". </take> <take id="point-2"> A metafunction evaluates a certain template argument lazily if it does not require the argument to be a fully instantiated type; otherwise, the evaluation is strict. The eval_if metafunction will strictly evaluate the second argument if the first argument is equivalent to false_; otherwise, it will strictly evaluate the third argument. </take> I'm less sure about point-2 than I am about point-1. In any case, feel free to correct any knowledge deficiencies I've exhibited, to make these definitions more complete. More examples would also be a great help. Cromwell D. Enage __________________________________________________ Do You Yahoo!? Tired of spam? Yahoo! Mail has the best spam protection around http://mail.yahoo.com

Cromwell Enage <sponage@yahoo.com> writes:
I remember a thread that ran for a while on this topic, and I need to make sure I've wrapped my head around it correctly.
I think you're referring to Vesa Karvonen's Lazy MPL (not sure if that's what he called it).
Here are my takes on laziness:
<take id="point-1"> A metafunction returns lazily if it can be used interchangeably with its return type.
I don't think that's the right way to think about it; Vesa's laziness is not about how things are returned, but about the treatment of arguments. A valid lazy metafunction argument is one that has a nested ::type. In other words, all lazy metadata are MPL nullary metafunctions. -- Dave Abrahams Boost Consulting www.boost-consulting.com

David Abrahams wrote:
Cromwell Enage <sponage@yahoo.com> writes:
I remember a thread that ran for a while on this topic, and I need to make sure I've wrapped my head around it correctly.
I think you're referring to Vesa Karvonen's Lazy MPL (not sure if that's what he called it).
Here are my takes on laziness:
<take id="point-1"> A metafunction returns lazily if it can be used interchangeably with its return type.
I don't think that's the right way to think about it; Vesa's laziness is not about how things are returned, but about the treatment of arguments. A valid lazy metafunction argument is one that has a nested ::type. In other words, all lazy metadata are MPL nullary metafunctions.
Is this 'lazyness' in the same sense as 'lazy evaluation'? In other words, does it mean you could write an MPL function that generated the entire list of Fibbonaci numbers by returning a (meta)function that generates the numbers up to the point they are needed?
participants (3)
-
Cromwell Enage
-
David Abrahams
-
Simon Buchan