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

[Balog Pal]

From: "Adrian Fagg" <adrianf at evaluategroup.com>
> > That leads to another phylosophy issue about UB.  A deal of my current
> > real-life headaches relate to UB, that is not thoroughly
> > specified by my
> > implementation, though I 'know' what will happen from other
> > sources.  (for
> > stuff practically unavoidable/necessary to use,  like reinterpret_cast
> > results cross pointers or integrals, overvlow of signed
> > integrals, etc.)
>
> I don't understand what you're driving at here.
> Undefined behaviour is something that you need to guarantee not to invoke.

We're probably lost in terms.  for some cases the standard do not define the
behavior, but the implementation is free to define it.   Say

int a = INT_MAX;
int b = a;
int c = a+b;

That is UB by the standard.  But if your implementation says, eg. 'int
overflow will wrap around just like you did the same with unsigned' you have
a well-defined behavior.

Certainly you shall not invoke "effective" UB. You can rely on locally
defined behavior, though keeping in mind you do that.

You absolutely can't avoid relying on locally defined behavior if say, you
use threads. Or other patform, or implementation specific stuff.   Sticking
to pure standard-defined behavior is no more than illusion for most of
today's C++ programmers.

> It shouldn't matter what that behaviour turns out to be, as you have to
> ensure that it doesn't happen.
>
> e.g. in the case of vector[] access, in real life, out of bounds will
either
> access a non existent object and blindly carry on or cause an access
> violation. As you don't know that it will do the latter and the
consequences
> of the former are in any case disastrous, you have to know that you won't
go
> out of bounds.

Sure.

OTOH, suppose your SL-provider documents 'vector::op[] does check bounds,
and calls terminate() on violation'. then that is the behavior, and you can
rely it, if you really want. for that case *I* wouldn't but see no ground to
boot someone else relying on that.

> However, as much real life code is multithreaded

Here you go.  Standard-wise as soon as you have another thread no behavior
is defined. :-)  You're on your own. Certainly wih the additional
documentation of your platform and implementation.   If you're lucky, you
find a firm documentation, in more general case you play on 'everyone does
that and seem to work' base. Or peek the sources.

> , a lot of run-time props
> turn out to be riddled with woodworm. e.g. testing for out of bounds when
> accessing an object without having acquired lock, cannot guarantee
> correctness.

For that case it's hopelessly flawed.  The bounds check will not save you --
it can be done while the bounds are valid, then become invalid by the time
of accessing the element.  Or invalidate the ref returned while you use it.
Relocate the vector data when you're halfway copying an element.

Thinking an embedded check (even one that implicitly grabs a lock, and make
the check and return utexed) is more secure for those situation is clearly
the highway to less secure programs.

> Hence the need to know that your code is correct.
> That is, run time checking is useful if it's part of the game plan but of
> very limited use 'just in case'.

Yeah.  Yeah. Yeah. :-)