Boost logo

Boost :

Subject: Re: [boost] Stack-based vector container
From: Bo Persson (bop_at_[hidden])
Date: 2011-01-17 12:37:26


Domagoj Saric wrote:
> "David Bergman" <David.Bergman_at_[hidden]> wrote in message
> news:FF46F967-E45E-4188-9976-6090F2054A51_at_bergmangupta.com...
>> What you are doing here is to mix two (presumably...) orthogonal
>> aspects, in that you bake in the allocation policy in the vector
>> interface. In fact, a "static allocator" to be used in cases like
>> std::vector
>> was discussed
>> at length on this list a year ago (or was it two years?)
>
> This is not quite the same, i.e. std::vector is 'too' generic so it
> would still incur overhead compared to a simple
> "stack-buffer-with-an-end-pointer": it contains (and maintains)
> three pointers (or std::size_ts) begin, end and "reserved end" as
> opposed to only an end pointer/std::size_t + it is designed around
> the 'idea' of "fallible allocation", that is it expects allocation
> requests to possibly throw so in some cases/member functions
> implementations have to use guard objects and/or explicit exception
> handling (which the optimizer may or may not be able to remove) ...
> and this same problem might obfuscate the code (for the compiler)
> enough so that the optimizer might not be able to detect that a
> 'std::vector with a static allocator' does not throw and cause it
> to still emit EH code/unwind funclets (for surrounding/calling
> code)...

If you have a fixed size vector, you cannot call functions that might
require a reallocation (push_back is out of the question). So the
compiler doesn't have to generate those functions at all.

Bo Persson


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