RE: [boost] [MPL] Making Generators
David Abrahams wrote: > Aleksey Gurtovoy <[EMAIL PROTECTED]> writes: > > Okay, from this moment MPL's lambda supports "reduced" > > metafunction form directly (if detected): > > > > template< typename T > struct her > > { > > // no 'type' member! > > }; > > > > typedef lambda< her<_> >::type f; > > typedef apply::type t; > > > > BOOST_MPL_ASSERT_IS_SAME(t, her); > > > > The "ordinary" metafunctions work as before. > > Ah! > > That answers my question... > > So if I want to generate a template instantiation that /happens/ to > have a nested type (that's not identity), I can't use the reduced > form. Not implicitly. The 'reduced< my_func<_> >' notation will solve that. > Interesting. You have to be a little bit careful with that reduced > form then. Sure :). But in majority of cases it gives you the most intuitive behavior. Aleksey ___ Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
Re: [boost] [MPL] Making Generators
Aleksey Gurtovoy <[EMAIL PROTECTED]> writes: > Aleksey Gurtovoy wrote: >> David A. Greene wrote: >> > Thanks for considering this. I think it will be quite >> > useful. I look forward to seeing what you come up with! >> >> Well, it turned out to be a little bit more complicated than >> I had foreseen, so it's not there yet. Please stay tuned! > > Okay, from this moment MPL's lambda supports "reduced" metafunction form > directly (if detected): > > template< typename T > struct her > { > // no 'type' member! > }; > > typedef lambda< her<_> >::type f; > typedef apply::type t; > > BOOST_MPL_ASSERT_IS_SAME(t, her); > > The "ordinary" metafunctions work as before. Ah! That answers my question... So if I want to generate a template instantiation that /happens/ to have a nested type (that's not identity), I can't use the reduced form. Interesting. You have to be a little bit careful with that reduced form then. -- David Abrahams [EMAIL PROTECTED] * http://www.boost-consulting.com Boost support, enhancements, training, and commercial distribution ___ Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
RE: [boost] [MPL] Making Generators
Aleksey Gurtovoy wrote: > David A. Greene wrote: > > Thanks for considering this. I think it will be quite > > useful. I look forward to seeing what you come up with! > > Well, it turned out to be a little bit more complicated than > I had foreseen, so it's not there yet. Please stay tuned! Okay, from this moment MPL's lambda supports "reduced" metafunction form directly (if detected): template< typename T > struct her { // no 'type' member! }; typedef lambda< her<_> >::type f; typedef apply::type t; BOOST_MPL_ASSERT_IS_SAME(t, her); The "ordinary" metafunctions work as before. Enjoy! Aleksey ___ Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
RE: [boost] [MPL] Making Generators
David A. Greene wrote: > Aleksey Gurtovoy wrote: > > It _is_ possible to implement a single template along the > > lines of the SHAZAM template you've mentioned early in the > > thread: > > > > template > > struct my_type { ... } // Note: no ::type member > > > > typedef SHAZAM > generator; > > > > typedef generator::template apply::type > my_type_inst; > > > > but not at the user side - the library internal mechanisms > > needs to be made aware of it. Actually, I lied - on a conforming compiler you can do the following: template< typename T, typename U, typename V > struct my_type {}; // Note: no ::type member // declare 'my_type' a "reduced" metafunction REDUCED_METAFUNCTION_SPEC(3, my_type) // test it typedef lambda< my_type >::type f; typedef f::apply::type t; BOOST_STATIC_ASSERT((is_same< t, my_type >::value)); where REDUCED_METAFUNCTION_SPEC is as simple as this: #define REDUCED_METAFUNCTION_SPEC(n, name) \ namespace boost { namespace mpl { \ template<> struct meta_fun##n< name > \ { \ template< BOOST_PP_ENUM_PARAMS(n, typename T) > \ struct apply \ { \ typedef my_type type; \ }; \ }; \ }} \ /**/ > > I considered this before, - as > > well as the option of directly supporting the "reduced" > > metafunction form, - and the latter is currently my > > preference. Will see if something changes after I actually > > implement it (for one, it might slow down the lambda > > significantly, - but we'll see). > > Thanks for considering this. I think it will be quite useful. I look > forward to seeing what you come up with! Well, it turned out to be a little bit more complicated than I had foreseen, so it's not there yet. Please stay tuned! Aleksey ___ Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
Re: [boost] [MPL] Making Generators
Aleksey Gurtovoy wrote: That's because the MPL's lambda works only with metafunctions which template parameters are _types_, and only types: That's what I suspected. 3) a metafunction with template template parameter, can't be used in lambda expressions: Again, what I suspected. It _is_ possible to implement a single template along the lines of the SHAZAM template you've mentioned early in the thread: template struct my_type { ... } // Note: no ::type member typedef SHAZAM > generator; typedef generator::template apply::type my_type_inst; but not at the user side - the library internal mechanisms needs to be made aware of it. I considered this before, - as well as the option of directly supporting the "reduced" metafunction form, - and the latter is currently my preference. Will see if something changes after I actually implement it (for one, it might slow down the lambda significantly, - but we'll see). Thanks for considering this. I think it will be quite useful. I look forward to seeing what you come up with! -Dave -- "Some little people have music in them, but Fats, he was all music, and you know how big he was." -- James P. Johnson ___ Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
RE: [boost] [MPL] Making Generators
David A. Greene wrote: > But consider this testcase: > > //#define CT_DEBUG > > //#include "ct_print.hh" > #include > #include > > template > struct my_type { > }; > > template > struct my_type_generator { >typedef my_type type; > }; > > template class Base, >typename T, typename U, typename V> > struct trivial_generator { >typedef Base type; > }; > > int main(void) > { >typedef my_type_generator generator; >//CT_PRINT(my_type_generator_result_is, generator::type); > >typedef trivial_generator t_generator; >//CT_PRINT(trivial_generator_result_is, t_generator::type); > >// Try to make some generators >typedef boost::mpl::lambda boost::mpl::_2> >::type lambda_generator; >typedef lambda_generator::apply lg_apply_result; >//CT_PRINT(lambda_generator_result_is, lg_apply_result::type); > >// Does not work >typedef boost::mpl::lambda boost::mpl::_1, boost::mpl::_2> >::type lambda_trivial_generator; >// g++ 3.2 claims apply doesn't exist. >typedef lambda_trivial_generator::apply ltg_result; >//CT_PRINT(lambda_trivial_generator_result_is, ltg_result::type); > >return(0); > } > That's because the MPL's lambda works only with metafunctions which template parameters are _types_, and only types: 1) a "canonical" metafunction, OK: template< typename T > struct identity { typedef T type; }; typedef lambda< identity<_> >::type f; BOOST_MPL_ASSERT_IS_SAME(f::apply::type, int); 2) a metafunction with non-type template parameter, can't be used in lambda expressions: template< typename T, int i = 0 > struct identity { typedef T type; }; typedef lambda< identity<_> >::type f; BOOST_MPL_ASSERT_IS_SAME(f::apply::type, int); // error! 3) a metafunction with template template parameter, can't be used in lambda expressions: template< typename T > struct something; template< typename T, template< typename > class F = something > struct identity { typedef T type; }; typedef lambda< identity<_> >::type f; BOOST_MPL_ASSERT_IS_SAME(f::apply::type, int); // error! Strictly speaking, (2) and (3) are not even metafunctions in MPL's terminology. > > >>But I can construct a generic trivial generator: > >> > >>template class Base, > >> typename T, typename U, typename V> > >>struct trivial_generator { > >>typedef Base type; > >>}; > >> > >>Then I can use MPL lambda facilities. Unfortunately, I need a > >>trivial_generator for every arity of class template. > > > > Only as part of the implementation. You just need a nice > > wrapper over the top to hide it all. > > Right. Can you point me to the MPL equivalent as a guide of > how to do this? Actually, even ignoring the aforementioned lambda issue, it's not possible to write a single template (a wrapper or not) that would take template template parameters of different arity - if it were, the library itself would use the technique to implement the single 'quote/mem_fun' template instead of providing the family of 'mem_fun1', 'mem_fun2', etc. constructs. It _is_ possible to implement a single template along the lines of the SHAZAM template you've mentioned early in the thread: template struct my_type { ... } // Note: no ::type member typedef SHAZAM > generator; typedef generator::template apply::type my_type_inst; but not at the user side - the library internal mechanisms needs to be made aware of it. I considered this before, - as well as the option of directly supporting the "reduced" metafunction form, - and the latter is currently my preference. Will see if something changes after I actually implement it (for one, it might slow down the lambda significantly, - but we'll see). Aleksey ___ Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
Re: [boost] [MPL] Making Generators
Aleksey Gurtovoy wrote: my_type is not a metafunction so maybe it just can't be used conveniently with mpl. Not now. However, I constantly keep finding more and more use cases to be inclined to provide a built-in library support for this particular metafunction's form - in particular, so that one could do exactly what you've tried to: typedef my_type my_type_generator; pass it to an algorithm, and it will work as expected. Yes, I've run into this need several times over the last couple of weeks. I've always defined custom generators for each of these types. and it might be useful as a library component. Thanks for the feedback! I would expect the feature to appear in the CVS somewhere on the weekend. Hey, that's great! Thanks for considering my suggestion. -Dave -- "Some little people have music in them, but Fats, he was all music, and you know how big he was." -- James P. Johnson ___ Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
Re: [boost] [MPL] Making Generators
David Abrahams wrote: I suppose not. What I really wanted was the ability to take a regular old template class and create a generator out of it: template struct my_type { ... } // Note: no ::type member typedef SHAZAM > generator; typedef generator::template apply::type my_type_inst; I want SHAZAM to be generic enough to take any template class, not just my_type. You can do that, up to N arguments, for some N. But consider this testcase: //#define CT_DEBUG //#include "ct_print.hh" #include #include template struct my_type { }; template struct my_type_generator { typedef my_type type; }; template class Base, typename T, typename U, typename V> struct trivial_generator { typedef Base type; }; int main(void) { typedef my_type_generator generator; //CT_PRINT(my_type_generator_result_is, generator::type); typedef trivial_generator t_generator; //CT_PRINT(trivial_generator_result_is, t_generator::type); // Try to make some generators typedef boost::mpl::lambda >::type lambda_generator; typedef lambda_generator::apply lg_apply_result; //CT_PRINT(lambda_generator_result_is, lg_apply_result::type); // Does not work typedef boost::mpl::lambda >::type lambda_trivial_generator; // g++ 3.2 claims apply doesn't exist. typedef lambda_trivial_generator::apply ltg_result; //CT_PRINT(lambda_trivial_generator_result_is, ltg_result::type); return(0); } Here's what g++ 3.2 tells me: lambda_test.cc: In function `int main()': lambda_test.cc:38: ISO C++ forbids declaration of `apply' with no type lambda_test.cc:38: template-id `apply' used as a declarator lambda_test.cc:38: typedef name may not be class-qualified lambda_test.cc:38: parse error before `;' token But I can construct a generic trivial generator: template class Base, typename T, typename U, typename V> struct trivial_generator { typedef Base type; }; Then I can use MPL lambda facilities. Unfortunately, I need a trivial_generator for every arity of class template. Only as part of the implementation. You just need a nice wrapper over the top to hide it all. Right. Can you point me to the MPL equivalent as a guide of how to do this? -Dave -- "Some little people have music in them, but Fats, he was all music, and you know how big he was." -- James P. Johnson ___ Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
RE: [boost] [MPL] Making Generators
David A. Greene wrote: > [Posted to boost because MPL is not yet released. At what > point should these questions go to boost-users?] It's mainly the content of the message that determines whether it should be posted here or to the Boost Users list; the status of the library - is it in development, pre-release, or released state - doesn't matter much. Boost Users is a gateway for, well, Boost users that feel overwhelmed and intimidated by the high volume and level of technical content that flows through this list. Basically, it's a place for newbie and frequently asked questions. If the question is highly technical - as the one I am replying to - it belongs here. > > Say I have a type my_type: > > template > struct my_type { ... } > > Now let's say I want to create a generator that > binds T to some type but leaves U and V free to > be filled in later. Basically, I want something > like this: > > template > struct my_type_generator { > template > struct apply { >typedef my_type type; > }; > }; > > Is there a convenient way to create this with MPL? > I thought lambda might do the trick, Yep, that would be intuitive, wouldn't it? > but apparently not: > > typedef my_type my_type_generator; > > (This will be passed to an MPL algorithm so I didn't > bother with lambda<>). > > This causes a static assertion in mpl::arg<2> where it > sees a void type for V (I think). Hmm, actually it should be something like this: error C2039: 'type' : is not a member of 'boost::mpl::meta_fun3::apply' but it doesn't matter much - you are right, it won't compile, currently. > > Is the problem that my_type doesn't contain a ::type > member? Yes. > my_type is not a metafunction so maybe it just > can't be used conveniently with mpl. Not now. However, I constantly keep finding more and more use cases to be inclined to provide a built-in library support for this particular metafunction's form - in particular, so that one could do exactly what you've tried to: typedef my_type my_type_generator; pass it to an algorithm, and it will work as expected. > It's easy enough > to manually define my_type_generator, but I think this > is a pretty common pattern Very! > and it might be useful as a library component. Thanks for the feedback! I would expect the feature to appear in the CVS somewhere on the weekend. Aleksey ___ Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
Re: [boost] [MPL] Making Generators
"David A. Greene" <[EMAIL PROTECTED]> writes: > David Abrahams wrote: > >>>Your correction above makes everything clear to me now. >> So do you feel you need an additional library feature? ;-) > > I suppose not. What I really wanted was the ability to take a > regular old template class and create a generator out of it: > > template > struct my_type { ... } // Note: no ::type member > > typedef SHAZAM > generator; > > typedef generator::template apply::type my_type_inst; > > I want SHAZAM to be generic enough to take any template class, > not just my_type. You can do that, up to N arguments, for some N. > If I understand your solution correctly, > it requires a manually-constructed generator for my_type: > > template > struct my_type_generator { >typedef my_type type; > }; > > SHAZAM then becomes mpl::lambda. > > The problem is, I'll have to create these trivial "generators" > (I hesitate to even call it that) many times over, once for each > class I want to bind. > > But I can construct a generic trivial generator: > > template class Base, > typename T, typename U, typename V> > struct trivial_generator { > typedef Base type; > }; > > Then I can use MPL lambda facilities. Unfortunately, I need a > trivial_generator for every arity of class template. Only as part of the implementation. You just need a nice wrapper over the top to hide it all. -- David Abrahams [EMAIL PROTECTED] * http://www.boost-consulting.com Boost support, enhancements, training, and commercial distribution ___ Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
Re: [boost] [MPL] Making Generators
David Abrahams wrote: Your correction above makes everything clear to me now. So do you feel you need an additional library feature? ;-) I suppose not. What I really wanted was the ability to take a regular old template class and create a generator out of it: template struct my_type { ... } // Note: no ::type member typedef SHAZAM > generator; typedef generator::template apply::type my_type_inst; I want SHAZAM to be generic enough to take any template class, not just my_type. If I understand your solution correctly, it requires a manually-constructed generator for my_type: template struct my_type_generator { typedef my_type type; }; SHAZAM then becomes mpl::lambda. The problem is, I'll have to create these trivial "generators" (I hesitate to even call it that) many times over, once for each class I want to bind. But I can construct a generic trivial generator: template class Base, typename T, typename U, typename V> struct trivial_generator { typedef Base type; }; Then I can use MPL lambda facilities. Unfortunately, I need a trivial_generator for every arity of class template. But I don't think there's any way around that. MPL needs the same thing for its placeholders. It just seems a shame that this enumeration needs to be repeated for this special case when it already exists for _1, _2, etc. I don't know... well, it could detect whether there was a ::type member, and if it were not present, it could just give you the outer class. I think that's a bit of a hack, though. Agreed. Urk...I'm not sure how to get around this problem without requiring template template parameters (beyond what's used for placeholders currently). There's no way. So what? Your compiler supports them. Of course. But others don't. I'm more concerned about the duplication of effort described above. But again, I don't think there's any way around that. -Dave -- "Some little people have music in them, but Fats, he was all music, and you know how big he was." -- James P. Johnson ___ Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
Re: [boost] [MPL] Making Generators
"David A. Greene" <[EMAIL PROTECTED]> writes: >> So do you feel you need an additional library feature? > > That's what I'm trying to find out. It seems like most of the > stuff is there already in MPL placeholders and binders. > >>>Plus your solution here doesn't bind T to a type. :) >> Are you just pointing out my error? > > Well...yeah. :) It wasn't meant as an attack. Wasn't taken that way. > I honestly was confused about what you presented. Understandably. > Your correction above makes everything clear to me now. So do you feel you need an additional library feature? ;-) >>>g++ 3.2. The MPL paper and docs don't say anything about >>>using placeholders or binders with classes that aren't >>>metafunctions. How would the binders know what to typedef >>>as apply::type? >> I don't know... well, it could detect whether there was a ::type >> member, and if it were not present, it could just give you the outer >> class. I think that's a bit of a hack, though. > > Agreed. Urk...I'm not sure how to get around this problem without > requiring template template parameters (beyond what's used for > placeholders currently). There's no way. So what? Your compiler supports them. -- David Abrahams [EMAIL PROTECTED] * http://www.boost-consulting.com Boost support, enhancements, training, and commercial distribution ___ Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
Re: [boost] [MPL] Making Generators
David Abrahams wrote: template struct my_type_generator { typedef my_type type; }; lambda does it Oops, I meant lambda > of course! Ok, that makes more sense now. :) , unless of course your compiler needs BOOST_MPL_AUX_LAMDA_SUPPORT. I don't think it's much of a savings, though. Not for one class, no, but when we're talking several classes with several binding requirements, I think there's a significant savings to be had. So do you feel you need an additional library feature? That's what I'm trying to find out. It seems like most of the stuff is there already in MPL placeholders and binders. Plus your solution here doesn't bind T to a type. :) Are you just pointing out my error? Well...yeah. :) It wasn't meant as an attack. I honestly was confused about what you presented. Your correction above makes everything clear to me now. g++ 3.2. The MPL paper and docs don't say anything about using placeholders or binders with classes that aren't metafunctions. How would the binders know what to typedef as apply::type? I don't know... well, it could detect whether there was a ::type member, and if it were not present, it could just give you the outer class. I think that's a bit of a hack, though. Agreed. Urk...I'm not sure how to get around this problem without requiring template template parameters (beyond what's used for placeholders currently). -Dave -- "Some little people have music in them, but Fats, he was all music, and you know how big he was." -- James P. Johnson ___ Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
Re: [boost] [MPL] Making Generators
"David A. Greene" <[EMAIL PROTECTED]> writes: > >> template >> struct my_type_generator >> { >> typedef my_type type; >> }; >> lambda does it Oops, I meant lambda > of course! > , unless of course your compiler >> needs BOOST_MPL_AUX_LAMDA_SUPPORT. I don't think it's much of a >> savings, though. > > Not for one class, no, but when we're talking several classes > with several binding requirements, I think there's a significant > savings to be had. So do you feel you need an additional library feature? > Plus your solution here doesn't bind T to a type. :) Are you just pointing out my error? >>>I thought lambda might do the trick, but apparently not: >>> >>>typedef my_type my_type_generator; >>> >>>(This will be passed to an MPL algorithm so I didn't >>>bother with lambda<>). >>> >>>This causes a static assertion in mpl::arg<2> where it >>>sees a void type for V (I think). >>> >>>Is the problem that my_type doesn't contain a ::type >>> member? >> Maybe. What compiler are you using? > > g++ 3.2. The MPL paper and docs don't say anything about > using placeholders or binders with classes that aren't > metafunctions. How would the binders know what to typedef > as apply::type? I don't know... well, it could detect whether there was a ::type member, and if it were not present, it could just give you the outer class. I think that's a bit of a hack, though. -- David Abrahams [EMAIL PROTECTED] * http://www.boost-consulting.com Boost support, enhancements, training, and commercial distribution ___ Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
RE: [boost] [MPL] Making Generators
> [mailto:[EMAIL PROTECTED]]On Behalf Of David A. Greene > Sent: 05 December 2002 16:56 > > > Is the problem that my_type doesn't contain a ::type > member? my_type is not a metafunction so maybe it just > can't be used conveniently with mpl. IIRC mpl::lambda does need metafunctions to work on. I don't know if that is the cause of yopur problem though. /ikh ___ Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
Re: [boost] [MPL] Making Generators
David Abrahams wrote: template struct my_type_generator { template struct apply { typedef my_type type; }; }; Looks good to me. Is there a convenient way to create this with MPL? You want it to be more convenient than that?! Perhaps "convenient" is the wrong word. There are several places I need to do this sort of thing and writing custom binders for each class (or generic generators with varying number of template template aritys) is tedious. Different argument positions must be bound for each of these generators, so that adds to the scalability problem of custom classes. Sometimes I want to bind different arguments to the same class. MPL binders seems the way to go. template struct my_type_generator { typedef my_type type; }; lambda does it, unless of course your compiler needs BOOST_MPL_AUX_LAMDA_SUPPORT. I don't think it's much of a savings, though. Not for one class, no, but when we're talking several classes with several binding requirements, I think there's a significant savings to be had. Plus your solution here doesn't bind T to a type. :) I thought lambda might do the trick, but apparently not: typedef my_type my_type_generator; (This will be passed to an MPL algorithm so I didn't bother with lambda<>). This causes a static assertion in mpl::arg<2> where it sees a void type for V (I think). Is the problem that my_type doesn't contain a ::type member? Maybe. What compiler are you using? g++ 3.2. The MPL paper and docs don't say anything about using placeholders or binders with classes that aren't metafunctions. How would the binders know what to typedef as apply::type? -Dave -- "Some little people have music in them, but Fats, he was all music, and you know how big he was." -- James P. Johnson ___ Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
Re: [boost] [MPL] Making Generators
"David A. Greene" <[EMAIL PROTECTED]> writes: > [Posted to boost because MPL is not yet released. At what > point should these questions go to boost-users?] > > Say I have a type my_type: > > template > struct my_type { ... } > > Now let's say I want to create a generator that > binds T to some type but leaves U and V free to > be filled in later. Basically, I want something > like this: > > template > struct my_type_generator { > template > struct apply { >typedef my_type type; > }; > }; Looks good to me. > Is there a convenient way to create this with MPL? You want it to be more convenient than that?! template struct my_type_generator { typedef my_type type; }; lambda does it, unless of course your compiler needs BOOST_MPL_AUX_LAMDA_SUPPORT. I don't think it's much of a savings, though. > I thought lambda might do the trick, but apparently not: > > typedef my_type my_type_generator; > > (This will be passed to an MPL algorithm so I didn't > bother with lambda<>). > > This causes a static assertion in mpl::arg<2> where it > sees a void type for V (I think). > > Is the problem that my_type doesn't contain a ::type > member? Maybe. What compiler are you using? > my_type is not a metafunction so maybe it just can't be used > conveniently with mpl. It's easy enough to manually define > my_type_generator, but I think this is a pretty common pattern and > it might be useful as a library component. H... -- David Abrahams [EMAIL PROTECTED] * http://www.boost-consulting.com Boost support, enhancements, training, and commercial distribution ___ Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
[boost] [MPL] Making Generators
[Posted to boost because MPL is not yet released. At what point should these questions go to boost-users?] Say I have a type my_type: template struct my_type { ... } Now let's say I want to create a generator that binds T to some type but leaves U and V free to be filled in later. Basically, I want something like this: template struct my_type_generator { template struct apply { typedef my_type type; }; }; Is there a convenient way to create this with MPL? I thought lambda might do the trick, but apparently not: typedef my_type my_type_generator; (This will be passed to an MPL algorithm so I didn't bother with lambda<>). This causes a static assertion in mpl::arg<2> where it sees a void type for V (I think). Is the problem that my_type doesn't contain a ::type member? my_type is not a metafunction so maybe it just can't be used conveniently with mpl. It's easy enough to manually define my_type_generator, but I think this is a pretty common pattern and it might be useful as a library component. -Dave -- "Some little people have music in them, but Fats, he was all music, and you know how big he was." -- James P. Johnson ___ Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost