|
Boost : |
From: David A. Greene (greened_at_[hidden])
Date: 2002-12-05 12:29:03
David Abrahams wrote:
>>template<typename Bound>
>>struct my_type_generator {
>> template<typename U, typename V>
>> struct apply {
>> typedef my_type<Bound, U, V> 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 <class T, class U, class V>
> struct my_type_generator
> {
> typedef my_type<T,U,V> type;
> };
>
> lambda<my_type_generator> 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<int, mpl::_1, mpl::_2> 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
Boost list run by bdawes at acm.org, gregod at cs.rpi.edu, cpdaniel at pacbell.net, john at johnmaddock.co.uk