Path: utzoo!utgpu!news-server.csri.toronto.edu!cs.utexas.edu!uunet!microsoft!jimad
From: jimad@microsoft.UUCP (Jim ADCOCK)
Newsgroups: comp.lang.c++
Subject: Re: C++ coding standards (Comment needed)
Keywords: standard,variables
Message-ID: <57167@microsoft.UUCP>
Date: 4 Sep 90 20:16:53 GMT
References: <56642@microsoft.UUCP> <41673@think.Think.COM> <56953@microsoft.UUCP> <2675@dataio.Data-IO.COM>
Reply-To: jimad@microsoft.UUCP (Jim ADCOCK)
Organization: Microsoft Corp., Redmond WA
Lines: 29

In article <2675@dataio.Data-IO.COM| bright@Data-IO.COM (Walter Bright) writes:
|In article <56953@microsoft.UUCP> jimad@microsoft.UUCP (Jim ADCOCK) writes:
|<In article <41673@think.Think.COM> barmar@think.com (Barry Margolin) writes:
|<<However, the compiler might decide to grow and shrink the stack frame each
|<<time the variable is created and destroyed.
|<Hm, do you know of any C++ compiler that actually grows and shrinks a
|<the stack within a routine? [in the absense if alloca()s]  A while back
|<I read a survey of C compilers that could identify no such compiler.
|
|There *are*, however, compilers that allocate variables on top of each
|other if their live ranges do not intersect. This has the same effect
|as adjusting the stack.
|
|	func()
|	{	{ int i; .... }
|		{ int j; .... }
|	}
|
|i and j's live ranges do not overlap, so they can (and do with some compilers)
|share the same storage location.
|
|<It turns out gotos in the language makes doing such problamatic.
|
|True if you actually are adjusting the SP, but not in the above scheme.

Yes, but C++ defines that destruction of named objects be on exit from
scope [with few exceptions], thus greatly restricting a compilers from
performing these optimizations on other than primitives.  Temporary
objects would be fair game for these optimizations, though....