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

Subject: Re: [boost] Interest in StaticVector - fixed capacity vector
From: Dave Abrahams (dave_at_[hidden])
Date: 2011-10-14 13:55:00

on Fri Oct 14 2011, Andrew Hundt <athundt-AT-gmail.com> wrote:

> 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.

I know those, of course.  Another one you failed to mention:
when you want to implement your own checking ;-)

> use case for checked:
> copying user input where you have a fixed length limit anyway due to
> other limitations, 

How do you use the exception in a correct program for this case?

> or the type of data being input, or any other case where performance
> is not important and correctness/lack of errors is.

Is throwing an exception going to turn an incorrect program into a
correct one?

>> 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.

Yeah... in that case they almost certainly don't want to pay for the
check.  But if they do want a check, how is an exception going to help
them?

> - 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.

Again, how does the exception help?  How do you use that?

> - 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.

These are all basically the same case AFAICT ;-)

-- 
Dave Abrahams
BoostPro Computing
http://www.boostpro.com