Path: utzoo!attcan!utgpu!news-server.csri.toronto.edu!cs.utexas.edu!tut.cis.ohio-state.edu!att!pacbell.com!pacbell!indetech!vsi1!octopus!sjsumcs!horstman
From: horstman@sjsumcs.sjsu.edu (Cay Horstmann)
Newsgroups: comp.std.c++
Subject: Re: Order of destructor calls for auto objects
Message-ID: <1990Dec21.192649.1100@sjsumcs.sjsu.edu>
Date: 21 Dec 90 19:26:49 GMT
References: <1990Dec14.221247.9487@lia> <martino.661601979@krypton> <1990Dec20.074232.9416@lth.se>
Reply-To: horstman@sjsumcs.SJSU.EDU (Cay Horstmann)
Organization: San Jose State University
Lines: 22

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