Steven Watanabe wrote:

There's nothing that works out of the box. Here's a quick hack:

Thanks for the suggestion. I'll see if I can adapt it to my situation. Scott

Steven Watanabe wrote:

typedef make_features >::type f1; typedef make_features >::type f2; typedef make_features::type f3; BOOST_MPL_ASSERT((boost::is_base_and_derived)); BOOST_MPL_ASSERT((boost::is_base_and_derived));

Sorry for taking so long to reply, but TMP always makes my head explode, and it takes a while to pick up the pieces and put them back together. In this case, I could have saved myself the explosion, because this interface offers behavior that is backwards from what I want. The conversion I want to allow is from fewer features to more, so I don't want f2 and f3 to be bases of f1, I want f1 to be a base for both f2 and f3. My current thinking is that this can't be done without knowing all possible features, so I'm thinking about an approach where I first define that: typedef mpl::vector< ... > AllPossibleFeatures; What I then want to define is template<typename MyFeatures> // sequence of features struct Features... subject to the following: typedef difference TypesToAdd; // Features in // AllFeatures that // are not in // MyFeatures For each type T in TypesToAdd, Features<MyFeatures> virtually inherits from Features::type>. So given typedef mpl::vector AllPossibleFeatures; Features (C++0x says I can omit the space between angle brackets :-}) would virtually inherit from Features> and Features. In turn, Features> and Features> would both virtually inherit from Features. I can write the difference metafunction above and I can write a rotate metafunction to help me iterate through all the types in the difference set. What I don't know is a good way to give Features<T> the appropriate number of virtual base classes. Can somebody help? Thanks, Scott

Steven Watanabe wrote:

The key thing to note is that you don't need to directly inherit from N base classes. You can create a two argument template and chain them together.

I knew that, but what with my exploding head and all, I didn't want to make any bigger mess at the outset than I had to. I figured I'd add that as a refinement later. Your revised code seems to behave exactly as I want, thank you VERY much. It will take me a while to really understand it, and I'm sure there will be head innards all over the place a few times, but I'm grateful for your speedy and detailed assistance. Scott

AMDG Scott Meyers wrote:

Steven Watanabe wrote:

...

template<class Sequence> struct MakeFeatures { typedef Features >

...

::type> type; };

I'm trying to understand the code you posted, but I'm having trouble, probably because I'm missing some basic concepts. I hope people here won't mind helping me with something I'm sure is basic: why do we need to make a copy of Sequence here? I've tried replacing the above typedef with

typedef Features<Sequence> type;

and everything breaks, so it's clear that the copy is there for a reason, but what is it?

The copy is to guarantee uniqueness. If you have a Features > this will not be the same as a Features >. The mpl::copy<> makes sure that Features<> always holds a type built by push_back on vector0<>. Thus, MakeFeatures >::type is the same as MakeFeatures >::type. Does that help? In Christ, Steven Watanabe