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 >
struct make_context_list
{
typedef typename mpl::reverse< typename mpl::push_front<
typename mpl::erase<
typename DestinationState::context_type_list,
typename mpl::find<
typename DestinationState::context_type_list,
CommonContext
>::type,
typename mpl::end<
typename DestinationState::context_type_list
>::type
>::type,
DestinationState
>::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 :)
Regards,
-- Andreas Huber When replying by private email, please remove the words spam and trap from the address shown in the header.