Re: [boost] Interest in StaticVector - fixed capacity vector

Subject: Re: [boost] Interest in StaticVector - fixed capacity vector
From: Andrew Hundt (athundt_at_[hidden])
Date: 2011-10-14 12:42:34

On Fri, Oct 14, 2011 at 6:32 AM, Dave Abrahams <dave_at_[hidden]> wrote:
>
> on Thu Oct 13 2011, Nevin Liber <nevin-AT-eviloverlord.com> wrote:
>
>> On 13 October 2011 18:08, Andrew Hundt <athundt_at_[hidden]> wrote:
>>> After comments by Nate Ridge, Dave Abrahams, and others, I have become
>>> convinced that push_back should be unchecked and exceeding the bounds
>>> should be undefined, with an option to turn on checking.
>>
>> While I really disagree with this (as there are both use cases for it
>
> Use-cases, please!

use case for unchecked:
copying point clouds, packets, geometry, or other sets of small
objects with fixed size through an intermediate buffer that either has
to be allocated frequently, where space is extremely limited, or where
allocation is simply not an option.

use case for checked:
copying user input where you have a fixed length limit anyway due to
other limitations, or the type of data being input, or any other case
where performance is not important and correctness/lack of errors is.

> Let's not overlook anything important in this discussion.
>
>> and, more importantly, it is no longer a drop in replacement for
>> vector because your push_back will now behave differently),
>
> How could it ever be a "drop-in replacement for vector" when it comes to
> exceeding a reasonably low length bound?  A vector is probably going to
> succeed to push_back past that bound, while this class definitely won't.
> Unless you plan to intentionally leverage this exception (in which case
> vector wasn't serving your needs, so your code needs more than a
> "drop-in-replacement" anyway), then it's *going* to change the behavior
> of your program if and when you cause it to be thrown.
>
> Maybe I'm missing something.

- Perhaps one uses vector while prototyping on their nice quad core 64
bit machine, then they need to cut things down and set strict limits
once the prototype works to get it on their cell phone, game console,
or even smaller device like a router or radio chip.

- On the completely opposite end of the spectrum, processing an extremely large
dataset that has fixed size datums. One could again prototype with vectors,
but now they need something a bit more constrained to optimize
performance for their datacenter.

- Yet another case is existing code that
uses vectors, but have a constraint that makes a perfect case for switching
to StaticVectors like the ones above.

I know there are other alternatives to achieve this, but it seems in
many cases it could be a good choice.

Cheers!
Andrew Hundt