From 629780152480017112
X-Google-Language: ENGLISH,ASCII-7-bit
X-Google-Thread: f78e5,bda3b729e5d0c564
X-Google-Attributes: gidf78e5,public
X-Google-ArrivalTime: 1993-04-05 07:25:32 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: bs@alice.att.com's message of 4 Apr 93 18:24:06 GMT
Message-ID: <KANZE.93Apr5161212@slsvdnt.us-es.sel.de>
Sender: news@us-es.sel.de
Organization: SEL
References: <C4vJy3.5FH@finnbogi.ocs.com> <25207@alice.att.com>
Date: 5 Apr 93 16:12:12
Lines: 47

In article <25207@alice.att.com> bs@alice.att.com (Bjarne Stroustrup)
writes:

|> Fobi@finnbogi.ocs.com (Obi Thomas @ Online Computer Systems, Inc.) writes 

|>  > Does the standard guarantee the order of calling destructors for automatic
|>  > objects? Suppose I have a situation like this:
|>  > 
|>  > void FooBar()
|>  > {
|>  >     Foo a;
|>  >     Bar b(a);
|>  >     ...
|>  > }
|>  > 
|>  > "b" stores a reference to "a" in its constructor and then needs to use the
|>  > reference in its destructor. Is this safe? Am I guaranteed that "a" is
|>  > destroyed after "b" so that the reference to "a" is valid in Bar::~Bar()?

|> There isn't an official standard yet, of course, but `yes' you can rely on
|> the order of destruction of named local objects to be the reverse of their
|> order of construction.

Does this hold for the following?

	void
	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?
--
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