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.