From: Andreas Huber (ahd6974-spamgroupstrap_at_[hidden])
Date: 2005-08-03 07:21:35
David Abrahams <dave <at> boost-consulting.com> writes:
> >> Why an mpl::list<>? What's special about that structurue? Why not
> >> mpl::vector?
> > The sequence just needs to support certain operations, e.g. push_front,
> > reverse, etc. So, mpl::vector<> should work too (I never checked).
> If you're reversing the sequence, all your arguments about requiring
> mutability for efficiency reasons are invalid. You might as well do
I don't think so, I'm only reversing the sequence *after* performing other
mutating operations on it. Here's an example from the current implementation
(context_type_list is assembled from multiple InnerInitial lists):
template< class CommonContext, class DestinationState >
typedef typename mpl::reverse< typename mpl::push_front<
>::type >::type type;
[I know that this code needs improvement]
> > Don't know, I can't think of anything that would keep you from using
> > deque or vector. I guess it would be best to document the exact
> > requirements and make measurements so that I can tell the user which
> > of the standard mpl sequences are best.
> Not a bad idea, but I wouldn't go overboard. In this case the first
> priority should be to lift needless restrictions.
I've actually already added two to-do items. The one dealing with the
restrictions appears before the measurements.
> The restrictions
> you're using don't even neccessarily lead to better efficiency.
Right, I got that :)
-- Andreas Huber When replying by private email, please remove the words spam and trap from the address shown in the header.