This is the mail archive of the gcc-patches@gcc.gnu.org mailing list for the GCC project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

Re: [rfc] coalesce stack slots


Nathan Myers wrote:
Richard Henderson wrote:

That and Nathan [Sidwell]'s VEC's appear to only be able to "add N to the current size" rather than "set total size to N". At which point I quit looking.


When we were designing the reserve() member of the C++ standard library template std::vector<>, several people thought its argument should be relative to the current capacity, but I insisted that reserve's argument should become the absolute capacity of the vector. (After a reserve() call, an append() is guaranteed not to trigger a reallocation if all the elements fit in the reserved size.)
hehe, I had that discussion with myself for this API :)

I "won", but I still find it hard to articulate precisely why it
was right.  If you can explain it, posterity might benefit.

The 'reserve' functionality we have is 'reserve space for N additional live members' _not_ space for N additional members on top whatever additional space is already there. Or another way to think about it is 'allocate space now so that the next N pushes/inserts won't reallocate' (so you can use the quick versions of those functions, rather than the slower ones). This has proved to be the right choice for the uses so far.

To get the std::vector semantics you'd have to add or subtract the
current live length (depending on which way you're going).

I've not yet looked at rth's code.

nathan

--
Nathan Sidwell    ::   http://www.codesourcery.com   ::     CodeSourcery LLC
nathan@codesourcery.com    ::     http://www.planetfall.pwp.blueyonder.co.uk



Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]