Boost logo

Boost :

Subject: Re: [boost] rationale for aux_/vector0.hpp (was Re: [mpl][docs]why use list?
From: Larry Evans (cppljevans_at_[hidden])
Date: 2009-04-06 09:11:06


On 04/06/09 00:23, Aleksey Gurtovoy wrote:
> On Sun, 29 Mar 2009 16:33:14 -0500, Larry Evans
[snip]
>
> This might be a historic artifact at this point. It's easy enough to
> verify: just change it to go negative and run the tests :).

Did that and it runs OK: However, I just ran the test on
the variadic version of gcc4.4.

>
>>> at_front indicates whether to use push_front or push_back. It's
>>> really a bool not an int.
>>>
>>
>> I understand; however, I really just wanted to know why the
>> items could be added from the front instead of the back.
>
> It makes vector a more versatile sequence at almost no cost, thus
> helping to avoid proliferation of different types of sequences user has
> to chose from.
>
> HTH,

Thank you Aleksey; however, I'm not sure I made myself clear.
I'm not wondering why vector has a push_back, I'm wondering
why the implementation here:

https://svn.boost.org/trac/boost/browser/trunk/boost/mpl/vector/aux_/preprocessed/typeof_based/vector10.hpp#L43

adds from the back instead of the front. IOW, instead of:

26 template<
27 typename T0, typename T1
28 >
29 struct vector2
30 : v_item<
31 T1
32 , vector1<T0>
33 >
34 {
35 typedef vector2 type;
36 };

why not:

26 template<
27 typename T0, typename T1
28 >
29 struct vector2
30 : v_item<
31 T0
32 , vector1<T1>
33 >
34 {
35 typedef vector2 type;
36 };

The reason for doing it this way is that the
variadic template compiler can be used as follows:

   template
   < typename Head
   , typename... Tail
>
   struct
vector
   < Head
   , Tail...
>
   : v_item
     < Head
     , vector<Tail...>
>
{
...
};

This compiler can't do it the other way because
the argument packs (e.g. Tail...) must occur at
the end and not at the beginning.

I've actually run the tests on this and they pass
the tests.

-regards,
Larry


Boost list run by bdawes at acm.org, gregod at cs.rpi.edu, cpdaniel at pacbell.net, john at johnmaddock.co.uk