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: <57324@microsoft.UUCP>
Date: 11 Sep 90 18:14:11 GMT
References: <56642@microsoft.UUCP> <41673@think.Think.COM> <56953@microsoft.UUCP> <2675@dataio.Data-IO.COM> <57167@microsoft.UUCP> <11190@spool.cs.wisc.edu>
Reply-To: jimad@microsoft.UUCP (Jim ADCOCK)
Organization: Microsoft Corp., Redmond WA
Lines: 41

In article <11190@spool.cs.wisc.edu> bothner@sevenlayer.cs.wisc.edu (Per Bothner) writes:
|jimad@microsoft.UUCP (Jim ADCOCK) writes:
|>|	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.
|>
|>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.
|
|Huh? "On exit from scope" means "at the end of the block"
|in this case, so there is no problem allocating i and j
|to the same location, even if their class(es) have destructors.
|
|Construction and destruction must by definition delimit an
|object's live range. Two variables in the same function,
|but defined in non-intersection blocks do not have overlapping
|live ranges. And can therefore share storage locations.

Sorry for the confusion.  I thought it was obvious that when I was talking
about constructors/destructors--that I couldn't be talking about the above "int"
examples.  [Ints, and other built-ins can use destructor syntax under 2.1+
compilers -- but those destructors do nothing, and so do not change 
traditional optimization issues]

Yes. two objects in two non-overlapping scopes in a routine are guaranteed 
to have only one in existance at any moment, allowing their space on the
stack to be shared.  My claim is simply that this is not common programming
practice.  Common practice is for most objects to be declared in the outer
-most scope of a function, where their destructors are not called until 
function exit.  Thus, the compiler doesn't get a chance to optimize based on
lifetime of most C++ objects.

I claim that optimizing based on the lifetime of objects in stack isn't a
big issue anyway.  The real issue is optimizing based on the lifetime of
objects in register.  Reusing a register saves time and code space.  
Reusing a stack slot only saves a little on the frame size.