Re: [boost] [mpl] as_sequence< X< Y > > instantiates typedefs inX<Y >

From: David Abrahams (dave_at_[hidden])
Date: 2005-08-02 22:32:32

"Andreas Huber" <ahd6974-spamgroupstrap_at_[hidden]> writes:

> David Abrahams wrote:
> [snip]
>> Why are you requiring that the user pass mpl::list<> as opposed to
>> some other mpl sequence?
>
> I need to modify that sequence internally. 

You don't mean that, exactly, since all metadata is immutable.

> If any sequence was allowed (including immutable ones), I would need
> to copy that sequence into an mpl::list<> first. 

Why an mpl::list<>?  What's special about that structurue?  Why not
mpl::vector?

Are you sure you couldn't get away with using some views onto the
original sequence?

> I suspect that the copying slows down compilation noticeably (I
> never had the chance to make measurements, so this may well be FUD),
> so I figured that requiring a list is the best way to give the user
> the opportunity to keep compilation as fast as possible. 

It's not; a vector would be faster.  Or you could just require any
front extensible sequence, in which case, maybe deque is what you
need?

> Sure, I could make a copy only if the user doesn't pass an
> mpl::list<> and document that in the interface but nobody has ever
> made a request in this direction. I guess this is due to the fact
> that pretty much everybody specifies the InnerInitial states inline:
>
> struct Y;
> struct Z;
> struct X : sc::simple_state< X, Machine, mpl::list< Y, Z > > {};

Why mpl::list and not mpl::vector or mpl::deque?

> That is, I can't really think of a real-world example where you would 
> want to use an algorithm to fill that list...
>
> Would you allow any mpl sequence anyway?

I certainly wouldn't require a list.  Whether to accept every possible
sequence is another question.  I'm sure there are many models of the
concept you actually need from the user.

-- 
Dave Abrahams
Boost Consulting
www.boost-consulting.com