From 3177468122248830316
X-Google-Language: ENGLISH,ASCII-7-bit
X-Google-Thread: f78e5,bda3b729e5d0c564
X-Google-Attributes: gidf78e5,public
X-Google-ArrivalTime: 1993-04-07 09:04:36 PST
Newsgroups: comp.std.c++
Path: gmd.de!ira.uka.de!slsvaat!josef!kanze
From: kanze@us-es.sel.de (James Kanze)
Subject: Re: Guaranteed order of destruction for auto objects?
In-Reply-To: maxtal@physics.su.OZ.AU's message of Tue, 6 Apr 1993 18:57:13 GMT
Message-ID: <KANZE.93Apr7175826@slsvdnt.us-es.sel.de>
Sender: news@us-es.sel.de
Organization: SEL
References: <25207@alice.att.com> <KANZE.93Apr5161212@slsvdnt.us-es.sel.de>
	<25220@alice.att.com> <1993Apr6.185713.18835@ucc.su.OZ.AU>
Date: 7 Apr 93 17:58:26
Lines: 57

In article <1993Apr6.185713.18835@ucc.su.OZ.AU>
maxtal@physics.su.OZ.AU (John Max Skaller) writes:

|> > > 	FooBar()
|> > > 	{
|> > > 		goto A ;
|> > > 	B :
|> > > 		Foo		a ;
|> > > 		goto C ;
|> > > 	A :
|> > > 		Bar		b ;
|> > > 		goto B ;
|> > > 	C :
|> > > 		// ...
|> > > 	}
|> > > 
|> > > (Note that b gets constructed before a.)
|> > > 
|> > > Or is this forbidden by the rule about jumping over an initializer?
|> >
|> >It is indeed not allowed to jump past an initializer (except of course if
|> >the initializer is in an inner scope that is completely bypassed by the
|> >jump).
|> >

|> 	Is there a rule about CALLING past an initialiser?

|> 	This came up when I was considering nested functions.
|> 	If there are forward declarations, it is possible
|> 	for a nested function to reference an uninitialised variable.

What language are you programming in?  There are no nested functions
in C++.  (Note that even functions declared in a class declared within
a function cannot access the local variables of the containing
function.)

|> 	Well, while trying to work out sensible rules that
|> 	would prevent this, it occured to me the problem
|> 	ALREADY exists anyhow for non-nested functions:

|> 	extern T g();

|> 	T x=g(); // does a 'goto' that skips past an initialisation
|> 	T y=k();
|> 	T g() { return y;}

|> The second question is whether this rule (or no rule :-) is
|> acceptable for nested functions.

This would seem to be just another variant of the initialization order
problem.  According to the ARM (and the present working draft of the
standard), this is legal, but the results are undefined.
--
James Kanze                             email: kanze@us-es.sel.de
GABI Software, Sarl., 8 rue du Faisan, F-67000 Strasbourg, France
Conseils en informatique industrielle --
                   -- Beratung in industrieller Datenverarbeitung