From -2881277393422492403 X-Google-Language: ENGLISH,ASCII-7-bit X-Google-Thread: f78e5,bda3b729e5d0c564 X-Google-Attributes: gidf78e5,public X-Google-ArrivalTime: 1993-04-09 08:40:58 PST Newsgroups: comp.std.c++ Path: gmd.de!newsserver.jvnc.net!howland.reston.ans.net!zaphod.mps.ohio-state.edu!caen!batcomputer!munnari.oz.au!metro!news From: maxtal@physics.su.OZ.AU (John Max Skaller) Subject: Re: Guaranteed order of destruction for auto objects? Message-ID: <1993Apr9.153146.8051@ucc.su.OZ.AU> Sender: news@ucc.su.OZ.AU Nntp-Posting-Host: physics.su.oz.au Organization: School of Physics, University of Sydney, Australia References: <25220@alice.att.com> <1993Apr6.185713.18835@ucc.su.OZ.AU> Date: Fri, 9 Apr 1993 15:31:46 GMT Lines: 99 In article kanze@us-es.sel.de (James Kanze) writes: >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++. Not yet:-) But I'm working on a proposal for it. Thats why I asked this question. What I want to know is this: if I propose nested functions, what should be made of this: f() { auto g(); // forward declaration of nested function f() { g(); } // define f, it calls g f(); // call f, which calls g T x="hello"; g() { cout < >|> 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. Yes, but its different in that, like the 'goto' problem, the bodies of the functions involved are always visible, or will soon be visible. For the initialisation order problem, there might be a call to an external function, so this problem is intractable. The nested function problem is solvable: the question is whether the restrictions involved in solving it are worth the effort. >According to the ARM (and the present working draft of the >standard), this is legal, but the results are undefined. Well, if I just propose nested functions, allowing forward declarations, and not prohibiting such undefined operations, when suitable restrictions might be crafted, would yo vote in favour of the unrestricted proposal or insist on examining a proposal with suitable restrictions? -- JOHN (MAX) SKALLER, INTERNET:maxtal@suphys.physics.su.oz.au Maxtal Pty Ltd, CSERVE:10236.1703 6 MacKay St ASHFIELD, Mem: SA IT/9/22,SC22/WG21 NSW 2131, AUSTRALIA