Re: [boost] [Boost-bugs] [ boost-Bugs-1617058 ] doc of placeholer expression requirements incomplete
Larry Evans wrote:
On 12/16/2006 10:23 AM, SourceForge.net wrote:
Bugs item #1617058, was opened at 2006-12-16 10:23 Message generated for change (Tracker Item Submitted) made by Item Submitter You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=107586&aid=1617058&group_id=7586
[snip]
Initial Comment: he 3 expression requirements on:
http://www.boost.org/libs/mpl/doc/refmanual/placeholder-expression.html
make no mention that X should have a nested type typedef. IOW, X must be a metafunction as defined here:
http://www.boost.org/libs/mpl/doc/refmanual/metafunction.html
However, I believe it should since I'm getting compile-time error messages without the nested typedef.
The tuple_methods_proto.cpp in <boost-vauilt>/Template Metaprogramming demonstates the problem.
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> >. In Christ, Steven Watanabe
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.
Larry Evans <cppljevans@cox-internet.com> writes:
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.
Maybe, but inheriting a nested ::type is such a fundamental pattern of use with MPL that I'm surprised you could have misunderstood this.
From the point of view of a client of X,
struct X { typedef int type; }; and struct Y { typedef int type; }; struct X : Y {}; are entirely equivalent. -- Dave Abrahams Boost Consulting www.boost-consulting.com
participants (3)
-
David Abrahams -
Larry Evans -
Steven Watanabe