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
