I cannot find anywhere in the ARM where the order of destruction of
automatic objects is defined.  Am I missing something?  If not, I propose
that the ANSI standard add the following to section 6.6 of the ARM:

  Objects are guaranteed to be destroyed in the reverse of their order
  of creation.

Take, for exampe, the following block:
  {
    foo a;
    foo b;
    foo c;

    count << "Hello world\n";

  }

We are already guaranteed that a will be constructed first, then b, then c,
according to section 6.7.  I want to also have the guarantee that on
exit from scope, first c will be destroyed, then b, then a.  This has
important implications for objects which reference other objects.

It appears that CFront 2.0 (from AT&T) already does this, but I would
like it to be formalized.

Comments?
--
Jeremy Grodberg      "I don't feel witty today.  Don't bug me."
jgro@lia.com

jgro@lia (Jeremy Grodberg) writes:

>I cannot find anywhere in the ARM where the order of destruction of
>automatic objects is defined.  Am I missing something?  If not, I propose
>that the ANSI standard add the following to section 6.6 of the ARM:

>  Objects are guaranteed to be destroyed in the reverse of their order
>  of creation.

>We are already guaranteed that a will be constructed first, then b, then c,
>according to section 6.7.  I want to also have the guarantee that on
>exit from scope, first c will be destroyed, then b, then a.  This has
>important implications for objects which reference other objects.

>It appears that CFront 2.0 (from AT&T) already does this, but I would
>like it to be formalized.

As a traditionalist (i.e. a C programmer who views C++ as a interesting
sideline rather then the future of the world) I can't honestly see that
the destruction of the object is the correct phrase for your ammendment.

Would it not be more accurate to refer to "the object destructor call",
which is a tidy-up operation targetted at (for example) freeing of
heap allocated memory, rather then the destruction of the object itself,
which is likely to ocurr on an out-of-scope by the stack pointer being
shifted to simultaneously "destroy" ALL the objects.

Semantics I will agree, but we are talking about an ammendment to the
defined standard...

P.S. is there really a case where there it is essential that one knows
the order of destruction, or is it just a case of planning inter-object
references in an appropriate way - this is NOT a flame, just a query.

Martin

--
DISCLAIMER: All My Own Work (Unless stated otherwise)
--------------------------------------------------------------------------
Martin O'Nions            Logitek Group Support      martino@logitek.co.uk
--------------------------------------------------------------------------
There's been an accident they said/Your servant's cut in half - he's dead!
Indeed said Mr Jones, then please/Send me the half that's got my keys.
         (Harry Graham - Ruthless Rhymes for Heartless Homes)

In article <martino.661601979@krypton> martino@logitek.co.uk (Martin O'Nions) writes:
>
>P.S. is there really a case where there it is essential that one knows
>the order of destruction, or is it just a case of planning inter-object
>references in an appropriate way - this is NOT a flame, just a query.

Yes, order of destruction can be essential in some applications.

In "Exception Handling for C++," Koenig and Stroustrup describe the
object-as-resource-allocator technique (Proc. C++ at Work, 1989).

 class Resource { .... };

 class Lock {
 public:
     Lock(Resource& r) : res(r) { res.allocate(); }
     ~Lock() { res.free(); }
 private:
     Resource& res;
 };

The idea is that creating a Lock object allocates some resource, which
is then freed when the Lock object is destroyed.

 void f(Resource& x)
 {
     Lock now(x);
     x.manipulate();
     int& i = x.data;
     // ....
 }

The Lock object `now' is destroyed when leaving function f, like any
other local variable, so `x' is automatically freed.  The beauty is
that this technique works even if we get an exception somewhere.
Another advantage is that you cannot forget to free a locked resource,
because you don't have to write the call explicitly.

The integer reference `i' clearly depends on `x' being locked, so here
is an example where I want objects to be destroyed in reverse order of
construction.  This is of course a trivial example, but it is not
difficult to imagine a case where the locking property is essential.

A related problem is when temporary objects are destroyed.  In many
cases the compiler may create temporary objects, and the user has no
control of when the temporaries are created or destroyed.
Unfortunately, the current language definition does not give any
constraints at all.  Using Cfront, I discovered that the approach above
worked in a particular case, but the "equivalent" code without
using a Lock object did not.  The C++ standardization committee has
noted this problem, and will surely resolve the issue.

Dag M. Bruck
--
Department of Automatic Control  E-mail: dag@control.lth.se
Lund Institute of Technology
P. O. Box 118    Phone: +46 46-104287
S-221 00 Lund, SWEDEN   Fax:    +46 46-138118

About order of destructor calls.

A quick glance in the index of the ARM tells me:

 Destructors for global objects within the same compilation unit
 are destroyed in reverse order of their construction.

 Destructors for class members are exceuted in reverse order of
 their construction.

 Destructors for base classes are exceuted in reverse order of
 their construction.

 Destructors for array elements are executed in reverse order
 of their construction.

The guarantee that I had expected to find but didn't:

 Destructors for named auto variables are executed in reverse
 order of their construction.

If it is not there it is an oversight that ought to be remedied.
I believe this to be non-controversial and that all compilers in
fact guarantees this.

I believe that this guarantee could also be given

 Destructors for local static variables are executed in reverse
 order of their construction.

but that this might be less obvious and therefore possibly controversial.
I'm sure X3J16 will consider this issue.

Note that complete determinism is probably not possible since the order
of evaluation or sub-expressions is not guaranteed by C or C++. This implies
that guarantees about the order of destruction of temporaries are hard
to make.

Also, the order of construction and destruction of global variables in
different compilation units are hard to guarantee. Given the diversity
of linkers and in particular the possibility of dynamic linking this
problem is fundamentally hard.

In article <1990Dec20.074232.9416@lth.se> dag@control.lth.se (Dag Bruck) writes:
>
>In "Exception Handling for C++," Koenig and Stroustrup describe the
>object-as-resource-allocator technique (Proc. C++ at Work, 1989).
>
>The idea is that creating a Lock object allocates some resource, which
>is then freed when the Lock object is destroyed.
>
>The Lock object `now' is destroyed when leaving function f, like any
>other local variable, so `x' is automatically freed.  The beauty is
>that this technique works even if we get an exception somewhere.
>Another advantage is that you cannot forget to free a locked resource,
>because you don't have to write the call explicitly.
>
Indeed this is very true. It is essential that destruction is guaranteed
to occur in reverse order of construction.

FURTHERMORE, it is also very important that objects get destroyed AS SOON
AS POSSIBLE. Many current implementations do not do that--unused objects,
especially temporary objects, may linger for quite a while.

Cay

In article <1990Dec21.192649.1100@sjsumcs.sjsu.edu> horstman@sjsumcs.SJSU.EDU (Cay Horstmann) writes:
>In article <1990Dec20.074232.9416@lth.se> dag@control.lth.se (Dag Bruck) writes:
>>
>>The idea is that creating a Lock object allocates some resource, which
>>is then freed when the Lock object is destroyed.
>
>FURTHERMORE, it is also very important that objects get destroyed AS SOON
>AS POSSIBLE. Many current implementations do not do that--unused objects,
>especially temporary objects, may linger for quite a while.

Well, "as soon as possible" may not be the ultimate goal for real-time
programmers; the most important requirement is that it SHOULD BE
DEFINED!

You can imagine several alternatives:

 1.  As soon as possible.
 2.  At the end of the current expression.
 3.  At end of statement.
 4.  At end of block.
 5.  At end of function.

Only #5 is completely useless.  I think my personal bias is for #2 or
#3, but this has to discussed further.  The reason why #1 is not the
best alternative is that it reduces the opportunity for optimization (so
I believe); I have also heard the argument that it would break a lot
of existing code that bends the rules slightly.

The standard should also specify when a temporary may be created; this
is natural requirement that often gets overlooked in the debate.

And finally, Merry Christmas and a Happy New Year.

Dag M Bruck
--
Department of Automatic Control  E-mail: dag@control.lth.se
Lund Institute of Technology
P. O. Box 118    Phone: +46 46-104287
S-221 00 Lund, SWEDEN   Fax:    +46 46-138118

In article <1990Dec21.192649.1100@sjsumcs.sjsu.edu> horstman@sjsumcs.SJSU.EDU (Cay Horstmann) writes:
>In article <1990Dec20.074232.9416@lth.se> dag@control.lth.se (Dag Bruck) writes:
>>
>>In "Exception Handling for C++," Koenig and Stroustrup describe the
>>object-as-resource-allocator technique (Proc. C++ at Work, 1989).
>>
>>The idea is that creating a Lock object allocates some resource, which
>>is then freed when the Lock object is destroyed.
>>[...]
>Indeed this is very true. It is essential that destruction is guaranteed
>to occur in reverse order of construction.
>
>FURTHERMORE, it is also very important that objects get destroyed AS SOON
>AS POSSIBLE. Many current implementations do not do that--unused objects,
>especially temporary objects, may linger for quite a while.

How would you define "possible".  There is no way for a compilier to know
when you are done with an object, other than when it goes out of scope,
and thus you have no way of accessing it.  If you use an object as a resource
allocator, then you may never ever reference the object after creating it.
Suppose, for example, I have a semaphore object which simply waits until
it can capture a semaphore, and holds the semaphore until it (the  object)
is destroyed.  It would be perfectly reasonable to write a function like:

void print(ImageType& image)
{
  semaphore printer(PRINTER_KEY); // capture the printer access semaphore

  // ...do a lot of stuff involved with printing.
}

Such a construct can only be useful if we are guaranteed that "printer"
will be constructed at the beginning of the function (which we are,
by E&S 6.7), and destroyed at the end of the function (i.e. where "printer"
goes out of scope).  E&S 6.6 does guarantee that destructors will be
called when objects go out of scope, and I strongly believe that they should
not be destroyed any earlier.


E&S 12.2 requires temporaries to be destroyed before the "exit from
the scope in which the temporary is created."  It would probably be
a good idea to upgrade the observation that "If [only] the value of a
temporary is fetched, that temporary is then dead and can be destroyed
immediately" to a full-fledged requirement that such destruction take
place before the next statement is executed.






--
Jeremy Grodberg      "I don't feel witty today.  Don't bug me."
jgro@lia.com

In article <1991Jan1.015110.329@lia> jgro@lia.com (Jeremy Grodberg) writes:
>
>E&S 12.2 requires temporaries to be destroyed before the "exit from
>the scope in which the temporary is created."  ....
>--
>Jeremy Grodberg      >jgro@lia.com

Unless, of course, a reference is bound to the temporary,
in which case the temporary must not be destroyed until the
reference is. This may require a temporary to exist beyond the
scope in which it is constructed. For example:

 struct T { };
 struct U {
  T & tr;
  U(T & r) : tr(r) { }
 };

 T maketemp() { T t; return t; }

 void foo()
 {
  U * p = new U(maketemp());
  return p;
 }

 main()
 {
  U * p = foo();
 }

In this example an object of type U gets created containing a
reference to a temporary T. How is the compiler to know when it
can destroy the temporary? This looks like a rather ugly problem.
Cfront seems to copy the temporary to the outer scope. So in fact, the
temporary gets destroyed more than once.
This example is not an error because it is also
constructed more than once, once with the
normal constructor and once with the copy constructor. But woe to the
programmer who neglects to build reference counts into his/her locks!
I'm sure than when aliases (pointers) are introduced a large number
of cfront (and other) compiler bugs are revealed based on lifetime
of temporaries.
---
Daniel Edelson                   |  C++ virtual garbage recycler:
daniel@cis.ucsc.edu, or          |    ``Recycle your garbage. Please don't
 ...!sun!practic!peren!daniel    |    make me come and copy after you.''

In his last article daniel@terra.ucsc.edu (Daniel Edelson) writes:
 <<<stuff that should have gone to comp.lang.c++ rather
 than comp.std.c++, please excuse...>>>
---
Daniel Edelson                   |  C++ virtual garbage recycler:
daniel@cis.ucsc.edu, or          |    ``Recycle your garbage. Please don't
 ...!sun!practic!peren!daniel    |    make me come and copy after you.''