pmoore@hemel.bull.co.uk (Paul Moore) (11/13/90)
Well a lot of conflicting opinions expressed - thanks. They range from
"desctructor calling specs are deliberately vague" to "it must be a bug"
via "you shouldnt do that anyway".
Tnaks to Reid Ellis for the test prog that showed that it is probably a bug
in the zortech compiler. His test prog was (paraphrased)
func()
{
cin >> i;
if (i==0)
return 0;
foo bar;
return 0;
}
with foo
class foo{
public:
~foo{cout << "foo destruct"};
};
This works fine - i tryed on my compiler. So I went back to my code and found
that I had oversimplified to example - changing the above to
func()
{
.....
if (i==0)
goto err_exit;
foo bar;
err_exit:;
return 0;
}
now fails - ie the constructor is not called but the destructor is. I'm sure
this proves that it is a bug in the zortech compiler since the behaviuor
must be consistent.
I'm still interested in what other compilers do as the lack of concensus
shows that this is not clearly defined.dcurtis@crc.ac.uk (Dr. David Curtis) (11/14/90)
<>func()
<>{
<> .....
<> if (i==0)
<> goto err_exit;
<>
<> foo bar;
<>err_exit:;
<> return 0;
<>}
<>now fails - ie the constructor is not called but the destructor is. I'm sure
<>this proves that it is a bug in the zortech compiler since the behaviuor
<>must be consistent.
<>
<>I'm still interested in what other compilers do as the lack of concensus
<>shows that this is not clearly defined.
I don't think it's fair to call this a bug. The Zortech manual has just such
an example (V2.0, p.203):
"Re: Using goto to skip initialisation
In C this may or may not cause problems, and is certainly bad style. In C++
it can be positively disastrous since the class definition might in fact call
a constructor which allocates memory, and for which a destructor will be
called later."
Quite so. If anything, this is a language problem, not a compiler problem.
Using goto to skip initialisation? Just say no.
Newsgroups: comp.lang.c++
Subject: Re: conditional scope and destructors results
Summary:
Expires:
References: <1990Nov13.114958.20853@hemel.bull.co.uk>
Sender:
Reply-To: dcurtis@crc.ac.uk (Dr. David Curtis)
Followup-To:
Distribution:
Organization: MRC Human Genome Resource Centre
Keywords: kaiser@ananke.stgt.sub.org (Andreas Kaiser) (11/17/90)
In your msg to All, dated <16 Nov 90 19:01>, it said:
PM> Tnaks to Reid Ellis for the test prog that showed that it is probably
PM> a bug in the zortech compiler. His test prog was (paraphrased)
PM> This works fine - i tryed on my compiler. So I went back to my code
PM> and found that I had oversimplified to example - changing the above to
PM> func()
PM> {
PM> .....
PM> if (i==0)
PM> goto err_exit;
PM> foo bar;
PM> err_exit:;
PM> return 0;
PM> }
PM> now fails - ie the constructor is not called but the destructor is.
PM> I'm sure this proves that it is a bug in the zortech compiler since
PM> the behaviuor must be consistent.
ARM, page 91:
"It is illegal to jump past a declaration with an explicit or implicit initializer unless the declaration is in an inner block that is not entered (...) or unless the jump is from a point where the variable has already been initialized."
Andreas
--
:::::::::::::::::::: uucp: kaiser@ananke.stgt.sub.org
:: Andreas Kaiser :: fido: 2:509/5.2512 & 2:507/18.7206
::::::::::::::::::::dcurtis@crc.ac.uk (Dr. David Curtis) (11/21/90)
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.
jimad@microsoft.UUCP (Jim ADCOCK) (11/28/90)
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. It would seem that a compiler would at least require a flow analyser to determine whether a jump might occur past an initializer in simple deterministic cases. Such a level of sophistication is not typically assumed of compilers in the design of languages. However, in other than simple deterministic cases it would seem that even compilers with flow analysers would not be able to determine if the jump will actually be executed or not. 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, send a warning in situations where the constructor might be so by-passed, and neither warn nor send an error in more complicated situations. Dumb compilers might do none of the above. In any case, since this is not a deterministic problem for compilers, it seems to me the intent of the prohibition was on programmers against such writing programs, not a requirement for compilers to detect such situations. Hopefully this is another situation where the ANSI committee will clarify the rights and responsibilities of compilers verses programmers.
philip@pescadero.Stanford.EDU (Philip Machanick) (11/29/90)
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
pmoore@hemel.bull.co.uk (Paul Moore) (11/30/90)
jimad@microsoft.UUCP (Jim ADCOCK) writes: >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 >of languages. However, in other than simple deterministic cases ....... >Hopefully this is another situation where the ANSI committee will >clarify the rights and responsibilities of compilers verses programmers. My personal thoughts are that the compiler must at least issue a warning. Non trivial cases of this problem are not easy to spot and occur in what seemed to me to be reasonbly shaped code - it took me some time to discover my problem. I think that the days where there was a book called "all the things that can go wrong with c but the compiler wont tell you" that you had to read have gone.
mat@mole-end.UUCP (Mark A Terribile) (12/01/90)
> > [Ellis and Stroustrup] 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. . . . > > I would suspect that smart compilers would cause a compiler time error > > if it can be assuredly determined that a constructor is being 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). There's a real problem with this real nice idea, to wit, what defines the algorithm that determines whether or not the compiler can `assuredly determine' that the declaration will never be elaborated? What strict, unambiguous, standard-suitable definition is to be found for the criteria against which a piece of code is to be tested? Will such a definition be USEFUL to the ordinary Sue, Ann, and Cheryl who are programming in C++? Would it be useful to the maintenance programmer who inadvertantly broke a flow-control assumption on which depended the correctness of some remote piece of code? Some of the answers might be acceptible if there were a well enough developed body of computing theory. In fact, little or none of our present computing theories can give us a good language with which to talk about this problem. -- (This man's opinions are his own.) From mole-end Mark Terribile
jimad@microsoft.UUCP (Jim ADCOCK) (12/11/90)
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.