On 12/16/2006 04:01 PM, Steven Watanabe wrote:
Larry Evans wrote: [snip]
type typedef. IOW, X must be a metafunction [snip] The problem is not with MPL lambda. The problem is here:
struct method_types<wrap_method_name<m_0>, TailMethods, FFC> : TailMethods {...};
TailMethods inherits from mpl::inherit2<field_types<f_0>, field_types<f_1> > which look like
struct mpl::inherit2 : T1, T2 { typedef inherit2 type; };
So, when you do not define type you inherit the base class version and applied_phe becomes mpl::inherit2<field_types<f_0>, field_types<f_1> >.
Ah! Thanks. Now it makes sense. There oughta be some caution about this "tripwire" in the docs for placeholder expressions because I've tripped over it several times. What's doubly confusing is that, as David says in followup comment to my bug report:
std::vector<_1> is a placeholder expression even though std::vector has no nested ::type.
so, I'm guessing that the: apply_wrapn< lambda<f>::type,a1,... an>::type mentioned on http://www.boost.org/libs/mpl/doc/refmanual/apply.html somehow detects whether f has a nested f<a1,...,an>::type, and if so, uses that as the result; otherwise, uses f<a1,...,an> as the result. IOW, std::vector<_1> qualifies as the "otherwise" case; hence, std::vector<int> is used as the result of apply. So, following the std::vector<_1> pattern, I thought: apply2 < method_types<_2,_1,X> , a1 , a2
::type
would result in: method_types<a2,a1,X> Instead, as you pointed out, the result was: a1::type since method_types<a2,a1,X> inherits from a1 and a1, in this particular case (ffc_fields_empty_base) had a nested type. Maybe a caution like: If the intended result of applyn<X,a1,...an>::type is X<a1,...an> then to assure this result, there should be, within the body of X, a nested: typedef X type; otherwise, if X<a1,...,an> has a supertype with such a nested typdef, it will be used instead of the intended result. within: http://www.boost.org/libs/mpl/doc/refmanual/placeholder-expression.html would avoid misunderstandings like mine.