Path: utzoo!utgpu!news-server.csri.toronto.edu!cs.utexas.edu!sun-barr!apple!bionet!agate!shelby!neon!pescadero.Stanford.EDU!philip
From: philip@pescadero.Stanford.EDU (Philip Machanick)
Newsgroups: comp.lang.c++
Subject: Re: conditional scope and destructors results
Message-ID: <1990Nov28.191327.8778@Neon.Stanford.EDU>
Date: 28 Nov 90 19:13:27 GMT
References: <1990Nov13.114958.20853@hemel.bull.co.uk> <329@tin.crc.ac.uk> <366@tin.crc.ac.uk> <13@microsoft.UUCP>
Sender: news@Neon.Stanford.EDU (USENET News System)
Reply-To: philip@pescadero.stanford.edu
Organization: Computer Science Department, Stanford University
Lines: 36

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:
|> |Jamshid Afshar has pointed out that I was wrong to say that it was not the 
|> |compiler's problem if you try to skip past an initialiser with a goto. In fact
|> |it is illegal to do this, so the compiler ought to flag it as an error
|> |rather than just tell you not to do it in the manual.
> 
> I disagree.  First, Ellis & Stroustrup do not make it clear whether this
> restriction is intended to be imposed on the programmer alone, or 
> whether this is something that it is mandatory for the compiler to 
> diagnose.  But, they do say it is illegal to jump forward past an 
> initializer -- not that it is illegal to write code that might permit
> a jump past an initializer.
Maybe there is a need for clearer wording. I can't find a specific definition
in E&S of "illegal", and the term is used relatively rarely - on a quick
glance, I found one other use (p.96), where it is clearly intended to be
synonymous with "error" (which I interpret as "compile-time error").
> I would suspect that smart compilers would cause a compiler time error
> if it can be assuredly determined that a constructor is being so
> by-passed [...]
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).
-- 
Philip Machanick
philip@pescadero.stanford.edu