Geoffrey Romer
On 10/6/05, David Abrahams
wrote: Geoffrey Romer
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
::type" is equivalent to a regular function call, and "metafunc " 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_