Path: utzoo!utgpu!news-server.csri.toronto.edu!clyde.concordia.ca!uunet!fernwood!portal!cup.portal.com!pkturner
From: pkturner@cup.portal.com (Prescott K Turner)
Newsgroups: comp.lang.c++
Subject: Re: Destruction Timing
Message-ID: <29583@cup.portal.com>
Date: 4 May 90 05:04:34 GMT
References: <1990Apr27.043710.2272@sjsumcs.sjsu.edu>
Organization: The Portal System (TM)
Lines: 28

I've thought a good deal about the way cfront times the destruction of
arguments, and it appears to be implementation convenience.  In cfront's
implementation, the calling function always constructs the argument.
This is more efficient because the calling function often must 
constuct an object to hold the argument's value anyway, so the object
gets used rather than copied via the copy constructor.  My guess is
that it's convenient for cfront to just put the argument object on
its stack of objects to be destroyed at the end of the block (in the
caller).

The caller has to destroy some argument objects anyway -- those passed
to ellipsis (...) parameter lists, because the callee doesn't necessarily
find out about them.

I agree with Cay that the "local arg" is local to the called function.
The fact that cfront declares it in the translation of the caller is
an implementation detail.  The AT&T language reference manual for C++
states that automatic objects are destroyed when they go out of scope.
That's what g++ reportedly does, not cfront.

I've heard that the NIH libraries rely on cfront's late destruction of
objects.  No doubt there's other code which is not portable for this reason.
Sometimes the following "works":
    C & func (C x) { return x; }
--
Prescott K. Turner, Jr.
13 Burning Tree Rd., Natick, MA 01760 USA    (508) 653-0357
UUCP: ...sun!cup.portal.com!pkturner    Internet: pkturner@cup.portal.com