"Andreas Huber" <ahd6974-spamgroupstrap@yahoo.com> 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