|
Boost : |
From: Daniel Frey (daniel.frey_at_[hidden])
Date: 2003-01-27 05:02:52
David Abrahams wrote:
>
> Daniel Frey <d.frey_at_[hidden]> writes:
>
> > On Sun, 26 Jan 2003 18:50:13 +0100, David Abrahams wrote:
> >
> >> Hum. It's fine to make Peter's particular example defined, but I'm a
> >> little concerned about asking to lift *all* undefined behavior for
> >
> > Maybe I'm missing something, but what about a pointer to some type T and
> > this:
> >
> > if( p ) p->f();
> >
> > If p is 0, p->f(); is undefined, isn't it? But just because the
> > expression may be undefined (given some conditions or not) cannot make
> > the whole program undefined if the expression is not executed, right?
> > Otherwise the language would be completly useless...
>
> Yes, but normally there's no way to detect that p will be 0 at
> compile-time. If, however, you write:
>
> T* p = 0;
> if (p) p->f();
>
> I think undefined behavior is allowed to be manifested during
> translation.
I don't think so. First of all: The standard should then say what is
compile-time detectable and what isn't, otherwise perfectly legal code
(which doesn't detect the 0 at compile-time) would turn into undefined
behaviour at the time compiler technology improves and detects the 0 at
compile-time. Well, as I am not a god, I cannot know what future
compilers will find out about my code, so how can I write legal code?
All that I would expect are better warnings. Secondly: When the compiler
cannot detect the 0 at compile-time, it still needs to be able to emit
some code for p->f(), whether it's called or not. This cannot interfer
with the rest of the program as long as it is not called. So even if it
detects the 0 at compile-time, why should this lead to undefined
behaviour? In my understanding, undefined behaviour can only occur for
code that is executed. Otherwise, everything that counts is whether it
compiles or not, but this doesn't make the whole programm undefined.
This is maybe a naive approach, but I fail to see how there can be any
other meaning of "undefined behaviour".
Regards, Daniel
PS: Should we take this to csc++?
-- Daniel Frey aixigo AG - financial training, research and technology Schloß-Rahe-Straße 15, 52072 Aachen, Germany fon: +49 (0)241 936737-42, fax: +49 (0)241 936737-99 eMail: daniel.frey_at_[hidden], web: http://www.aixigo.de
Boost list run by bdawes at acm.org, gregod at cs.rpi.edu, cpdaniel at pacbell.net, john at johnmaddock.co.uk