[interfacekit] Re: oddish?

On 2004-02-25 at 11:04:10 [+0100], Andrew Bachmann wrote:
> Ingo Weinhold <bonefish@xxxxxxxxxxxxxxx> wrote:
> > 
> > On 2004-02-16 at 17:28:58 [+0100], Marcus Overhagen wrote:
> > > A temporary BString object is created, initalized with "test".
> > > Then a pointer to the (copy) of the string inside the BString
> > > object is returned by the String() function, and pushed on the
> > > stack. Now the expression is evaluated, and the temporary
> > > BString object is destroyed. Now the function bar() is executed,
> > > using the pointer that is on the stack, but no longer valid since
> > > the temporary object was already destroyed.
> > 
> > I don't believe this is true. AFAIK temporary objects are not destroyed at
> > the end of an expression, but at the end of a statement; that is in your
> > example after bar() returned. Attached is a little program that executes 
> > two
> > tests, which demonstrate that behavior. The second test is of particular
> > interest, since it also shows how buggy our gcc is -- the B destructor is
> > invoked twice on the same object. mwcc does it correctly though, 
> > destroying
> > B after A.
> 
> Marcus is right in the spec sense,

Yep, I just looked it up in the standard and it indeed states quite clearly:

`The lifetime of a parameter ends when the function in which it is defined 
returns.'

With `lifetime' for objects of classes with constructor and destructor being 
intuitively defined as the time span between returning from the constructor 
and entering the destructor.

> Ingo is right in the realized sense of
> our gcc.  Ingo's observation is the basis of my warning.  I understand that
> Marcus is right, but our gcc is (at least sometimes) wrong. :-P  Ours seems 
> to
> be not the only gcc with this problem, however I don't have a full
> characterization of which gcc do exhibit it.

I originally tested with version 3.3.2 and the code it produces behaves as 
desired. I re-checked with 2.95.3 and it appears to be broken, too.

> Hence, my encouragement to
> rewrite these type of expressions to not exercise that part of the spec.

Or rather not exercise that non-part of the spec. ;-)

CU, Ingo

Other related posts: