Path: utzoo!attcan!uunet!microsoft!jimad
From: jimad@microsoft.UUCP (Jim ADCOCK)
Newsgroups: comp.lang.c++
Subject: Re: conditional scope and destructors results
Message-ID: <59675@microsoft.UUCP>
Date: 10 Dec 90 19:36:53 GMT
References: <1990Nov13.114958.20853@hemel.bull.co.uk> <329@tin.crc.ac.uk> <366@tin.crc.ac.uk> <13@microsoft.UUCP> <1990Nov28.191327.8778@Neon.Stanford.EDU>
Reply-To: jimad@microsoft.UUCP (Jim ADCOCK)
Organization: Microsoft Corp., Redmond WA
Lines: 32

In article <1990Nov28.191327.8778@Neon.Stanford.EDU> philip@pescadero.stanford.edu writes:
>In article <13@microsoft.UUCP>, jimad@microsoft.UUCP (Jim ADCOCK) writes:
>|> In article <366@tin.crc.ac.uk> dcurtis@crc.ac.uk (Dr. David Curtis) writes:
>Maybe this is impossible to do in general, but it should be possible to
>use a conservative strategy. For example, cfront 2.0 throws out the following
>
>int i=1;
>if (i!=1)  goto L123;
>float x=0.0;
>L123:
>
>even though the goto will never be executed. There's a case for tightening
>up the wording, but I believe the responsibility for detecting potential
>errors of this kind should rest with the compiler, even if it occasionally
>results in minor inconvenience (through the adoption of a conservative
>strategy).

I don't disagree.  My argument is with what the ARM presently says or
doesn't say.  The ANSI-C spec clearly using the word "jump" to mean that
which happens during the dynamic execution of a program, whereas a 
"jump statement" is what exists at compile time.  The informality of
a reference manual [like the ARM] allows such ambiguities to exist.  Hopefully,
when we have a formal ANSI-C++ spec, these kinds of ambiguities will
not exist -- such being the difference between a reference manual and a 
complete spec.

As you point out, either one prohibits a "jump statement" referencing 
a target label past a constructor, in which case compilers can conservatively
prohibit all such constructs, or one prohibits a "jump" past a constructor,
in which case compilers can only catch those "jumps" which can be predicted
at compile time.  I can't think of any good reason why it shouldn't be
the "jump statement" that is prohibited.