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-15 00:06:30

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

>>>> 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,"
>
> I'm fairly certain that writing specifications this way is quite
> common. 

I was asking about you, personally.

> For instance, consider a program that catches exceptions and crashes,
> then generates and sends a bug report to the creators. Does that
> application not catch when the code is wrong, then do something
> reasonable? 

Its specification doesn't say "do something reasonable;" it says "send a
bug report to the creators."  

> Of course this is not correct behavior with respect to the original
> goal, but I would argue that is is correct behavior with respect to a
> secondary goal of finding incorrect behavior that prevents reaching
> the original goal.

Sure, but exceptions are a poor way to get that effect.

> Furthermore, I don't believe I am being very original with this idea.
> Java has the ArrayOutOfBounds exception. Please, I beg you not to take
> this as the belief that Java is correct. I am simply unconvinced by
> your argument and I am playing devil's advocate by pointing out an
> example counter to the point you are making.

I don't know what to say.  Java is a mostly-different story; they have
no undefined behavior in the language, so they have to do something
else.  IMO using EH to deal with programming errors is usually a
mistake, but it's one that's been repeated far and wide.

>> More precisely, it avoids some undefined behaviors, which has some
>> security benefits. Â That's why I proposed the SEMISECURE mode.
>
> Why should the mode be SEMISECURE by default, and not a
> RELAXED_SECURITY mode for when you absolutely need the highest
> performance?

Everybody wants a different default; I'm not here to argue about that
except that I'll say people get upset when they turn on all the
optimizations and then pay for checks they weren't expecting.

> also, what is the disadvantage of providing, push_back(),
> checked_push_back(), and unchecked_push_back(), where a policy or
> struct tag allows the checkedness (pardon my word frankenstein) to be
> decided at either the instantiation or the call site, respectively?

Creeping—nay, rampaging—complexity.

> To draw an analogy, designing code to use RAII can sometimes incur a
> performance penalty with the benefit of preventing a failure to
> release a resource. Of course you can always "just free" that resource
> by hand, but changes in one portion of an application can have
> unforeseen consequences in another to those who are dealing with a
> small portion of a very large or complex system. Therefore it has
> become commonplace to pay a small penalty for the benefit of
> preventing problems. In this case, that problem is undefined behavior,
> and the penalty is the checks. Perhaps an out of bounds error does not
> meet the complexity level required for such a cost to be worthwhile,
> but if I am not mistaken myself, it is one of the most common mistakes
> made by anyone. However, this does not prevent one from making the
> other choice, and calling the unchecked version when they absolutely
> need the performance.
>
> The core of what I am saying is that checks + exceptions make it
> easier to find, prevent, and/or report problems.

The checks are not the problem; the exceptions are.  And they don't help
with finding, preventing, or reporting problems.

> There are a some items I would like to verify so I can clarify my
> understanding of your argument.
>
> First, I believe that you are saying that code is already incorrect
> when it goes out of bounds, 

Probably.

> so you might as well just let it keep running with undefined behavior
> unless a special SEMISECURE flag is set. 

No.

> Furthermore, by the time you reach the point where I am proposing that
> an exception be thrown, the code is already incorrect, therefore the
> exception will never prevent an error, and thus the exception should
> not exist. Is this correct?

That's one way to look at it, but it's not what I said.  The main
problems are the ones I cited before in this thread (you can go back and
look them up).

> What are the metrics by which you define an exception as both
> incorrect and/or worse? What is lost by using an exception? Does it
> break a convention, reduce performance, break purity, or upend general
> happiness?

All answered already in my first posting in the thread.

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