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 16:41:13

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

>>> 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?
>
> ah, exceptions in a correct program! I don't believe I have ever seen
> a program that is both nontrivial and correct :-)
>
> I cannot think of cases where given a correct program an exception
> should be thrown with a fixed capacity vector, aside from testing that
> the exceptions are thrown correctly :-). As far as I can think at the
> moment, if your program is correct you should never exceed the
> capacity of a fixed size vector.
>
>>> 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?
>
> If you catch that exception and do something reasonable, would it not?

No.  "Reasonable" doesn't mean you fulfill your original
intention/specification.  You don't normally write specifications that
say, "...unless the code is wrong, in which case I'll do something
reasonable," nor do you code to perform an operation in two different
ways in case one of them turns out to have coding errors, do you?

> Perhaps this only makes the argument of making it "less wrong".

Is that like "less pregnant?"

More precisely, it avoids some undefined behaviors, which has some
security benefits.  That's why I proposed the SEMISECURE mode.

>>>> 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?
>
> Black box:
> If you have to use an existing algorithm or function that you cannot
> change or do not know exactly how the internals work, you can catch
> the exception and handle it in a reasonable way.

Too much hand-waving.  What possible "reasonable way?"  Are you going to
try to achieve the same semantics in a different way?

[And why "how the internals work" matters is beyond me].

> Alternately, if you are creating the black box, you could do the same
> for the data they give you.

Ditto

> Prototyping:
> I find exceptions helpful when they immediately kill my program when I
> do something wrong at the prototyping stage, as compared to random
> stack jumps into other places when I'm just allowed to try and access
> that memory. Much easier to find and fix quickly :-)

Thus a recommendation for a SEMISECURE mode where you can tune the
response.  The builtin assert() facility almost always kills your
program at /least/ as usefully and quickly as an exception.

>>> - 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?
>
> The execution of what?

Did I write "execution?"

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