Geoffrey Romer <geoff.romer@gmail.com> writes:
On 10/6/05, David Abrahams <dave@boost-consulting.com> wrote:
Geoffrey Romer <geoff.romer@gmail.com> writes:
If so, doesn't that mean Cromwell's fix is incorrect?
I'm afraid I've not seen his fix.
I'm also afraid I don't have time to look at it right now.
Fair enough. It's sort of a side issue anyway.
What I don't understand is when I should be saying "typename metafunc<args>::type" and when I should be using plain "metafunc<args>". This isn't a language-correctness issue, it's an MPL usage issue.
Oh. Maybe mapping into the runtime world will help. If you think of metafunc as a regular function, then "metafunc<args...>::type" is equivalent to a regular function call, and "metafunc<args...>" is equivalent to boost::bind(func, args...)
These are exact analogies, AFAICT.
OK, that's what I thought, but it seems not to apply to lambda-expressions. If I want to call foo<> on a placeholder
I don't know what you mean, but I'm pretty sure you don't mean what you said. Nobody but the MPL internals want to actually invoke metafunctions on placeholders. Very often that will cause an error, because the placeholder does not meet the expectations of the metafunction for the type that is actually supposed to be passed to it.
I seem to be required to write foo<_1>, and not typename foo<_1>::type, even though I want foo<> to actually be applied to the placeholder (after substitution). What am I missing?
Well, it's the "after substitution" bit. For the reasons described above, you can't in general instantiate foo<_1>, and even if you did, the result might be int, e.g. template <class T> struct foo : mpl::if_<boost::is_pointer<T>, T, int> {} // foo<_1> => int and there's no information left in the type int that can tell the library where to make a substitution, or even what template into which it should be substituted. So, in placeholder expressions, you want to delay evaluation, and you don't actually add the ::type. HTH, -- Dave Abrahams Boost Consulting www.boost-consulting.com