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

Adrian Fagg adrianf at evaluategroup.com
Wed Oct 27 08:34:26 EDT 2004


> -----Original Message-----
> From: effective-cpp-bounces at accu.org
> [mailto:effective-cpp-bounces at accu.org]On Behalf Of Balog Pal

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

If there is a level at which you don't know, then you have to choose whether
to pre test or to use at() and deal with the library exception.

However, as much real life code is multithreaded, 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. 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'.


Regards,

Adrian

Work: mailto:adrianf at evaluategroup.com
Home: mailto:adrian.fagg at ntlworld.com

Pretty pictures: http://homepage.ntlworld.com/rbyadf/




More information about the Effective-cpp mailing list