AMDG Larry Evans wrote:
Now, on a related matter,
what's the rationale for vector0::lower_bound_::value == 32768
push_front decreases lower_bound_, and the lower_bound_ needs to stay positive. the lower_bound_ in vector zero needs to be fairly high to avoid problems. There is no reason why it has to be exactly 32768.
as shown here:
https://svn.boost.org/trac/boost/browser/trunk/boost/mpl/vector/aux_/vector0...
and what's the rationale for at_front=0 here:
https://svn.boost.org/trac/boost/browser/trunk/boost/mpl/vector/aux_/item.hp...
The only reason, AFAICT, for the at_front value is that the vectorI specializations here:
https://svn.boost.org/trac/boost/browser/trunk/boost/mpl/vector/aux_/preproc...
for some reason add items starting from the tail, as shown at:
https://svn.boost.org/trac/boost/browser/trunk/boost/mpl/vector/aux_/preproc...
However, if the items were added from the head, then at_front=1 could be used. The reason that would be desirable is that it enables the variadic template compiler to used to simplify the mpl::vector implementation, as shown here:
TinyURL.com/cof5br at_front indicates whether to use push_front or push_back. It's really a bool not an int.
In Christ, Steven Watanabe