[Effective-cpp] Item 1: Uses and Abuses of vector

[Herb Sutter]

>It may be low, but that still breaks the 'not pay for what you not use'
>rule.

Why is that? You don't have to use the container.

>But the real problem is not the cost of the check, but the action if
the
>range problem is discovered.
>
>Leaving it undefined gives way to do anything *good* for a quality
>implementation,

I assume you mean requiring range checking but leaving undefined what
happens if a range check is violated? That is essentially synonymous to
the status quo, because it means nothing to require a range check
without specifying that the behavior is something other than undefined.

Undefined behavior is the worst of all possible behaviors. Anything,
even unspecified or implementation-defined behavior, is better than
that.

>like asserting in debug, and no check in release build, or
>terminate() in release build, or make it tunable by switch, then still
>remain conforming.
>
>Defining the behavior would take that freedom away.   And force
something
>possibly good for one group and bad for others.

How is this different from when the standard library throws an exception
when it encounters an error? You could argue that it should allow the
freedom for operator new to assert instead, or some such, right?

Besides, this is the whole reason for the out_of_range exception type.

>> and
>> continues to drop; predict the branch the right way and the cost can
be
>> near-zero even in the increasingly rare truly CPU-bound code where it
>> could matter. At the same time, safety and security are increasingly
>> important. Having range checking off by default is therefore
>> increasingly difficult to defend. It has to be easy to write safe
code,
>> and code that is safe by default.
>
>Sure. Just we must first agree what is 'safe code'. Then look how the
check
>really grants security and is not just another pack of snake oil.

For range checking in particular, the easy objective measure is whether
the check turns undefined behavior into another kind of behavior
(preferably well-defined behavior). The check is "snake oil" iff it
leaves the behavior undefined. Beyond that, IMO unspecified or
implementation-defined behavior is only moderately better, and for my
liking the check is not very useful unless the behavior is well-defined.

For safe code in general, type safety is well-defined (and to get it in
C++ you have to avoid a number of constructs).

Herb