on Thu Mar 29 2007, Scott Meyers
David Abrahams wrote:
:) Not much of an advance. Try "studying my detailed elaboration" and let me know if that's still the case.
Things are better, thanks primarily to Joaquín M López Muñoz's helpful explanation. Part of my confusion, I think, can be traced to the design decision behind this comment of yours:
mpl::set<...> may actually have a ::type member (essentially a typedef for mpl::set<...> itself), but if so it's just there as a convenience for use with constructs like eval_if.
...
There's a class of metafunctions that usually don't need to be explicitly invoked: those whose range of results is limited in certain ways. In practice this turns out to mean metafunctions with numeric/boolean results.
The convenience you write of is real, but it also means that some metafunction invocations need no ::type, but others do. Without understanding the rules in some detail, it's hard to figure out when ::type is required. The MPL design chooses convenience over consistency, and at the beginning of the learning curve, my personal opinion is that consistency is more important than convenience. For experienced users, of course, the balance point may be -- probably is -- at a different location.
You're still free to use all the unnecessary typename ... ::type incantations if you want to be consistent and safe. Vesa Karvonen's "Lazy MPL," which I mentioned in an earlier posting, would probably be much easier overall because it only needs ::type in a very few well-defined places. -- Dave Abrahams Boost Consulting www.boost-consulting.com Don't Miss BoostCon 2007! ==> http://www.boostcon.com