Dave Abrahams wrote:
on Sun Jul 17 2011, Edward Diener <eldiener-AT-tropicsoft.com> wrote:
I think the nullary type syntax is cleaner syntactically and easier to use. There may be a better solution for this sort of thing, but I am looking for simplicity.
The whole idea, syntactically, of the nullary type metafunctions is that one passes around the metafunction itself rather than its nested type, so there is much less of the ::type in the syntax. It does involve using a separate set of boost::tti::mf_xxx metafunctions and passing metafunctions as data, but I feel that the syntactical gain is worth it.
I really will update my documentation so that I will compare the macro metafunction and nullary type metafunction usage together when dealing with all of the cases of using the non-composite macro metafunctions.
I will admit to not knowing any of the background here, so what I'm about to say may be totally irrelevant but...
One can build a completely lazy MPL if you say that everything has to be a metafunction: all types are wrapped in nullary metafunctions before they are used, so you don't reach in and grab the nested ::type until you are ready to get the final result of your computation. Vesa Karvonen was the first one to do this IIUC. Unfortunately my experiments have revealed that if you rely on this idiom everywhere you get horrible compile-time performance.
FWIW-ly y'rs,
Does this mean that if I use the nullary metafunciton macros to gain syntactical convenience, I will pay in compile-time performance? Again, this should be clarified and _quantified_ in the docs so as a user I can make an informed choice when you offer multiple choices for the same functionality. For example, the TTI authors should please measure and compare compile-times within and without nullary metafunctions for some version of MVSC and GCC and add it to the docs (and please do the same of MTFC). Thanks, --Lorenzo -- View this message in context: http://boost.2283326.n4.nabble.com/TTI-Review-tp3658414p3675578.html Sent from the Boost - Dev mailing list archive at Nabble.com.