Boost logo

Boost :

From: Larry Evans (cppljevans_at_[hidden])
Date: 2006-12-17 10:11:08

On 12/16/2006 04:01 PM, Steven Watanabe wrote:
> Larry Evans wrote:
>>>>type typedef. IOW, X must be a metafunction
> 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
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:

   < method_types<_2,_1,X>
   , a1
   , a2

would result in:


Instead, as you pointed out, the result was:


since method_types<a2,a1,X> inherits from a1 and a1, in
this particular case (ffc_fields_empty_base) had a nested

Maybe a caution like:

   If the intended result of applyn<X,a1,>::type
   is X<a1,> 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


would avoid misunderstandings like mine.

Boost list run by bdawes at, gregod at, cpdaniel at, john at