🚀 go-pugleaf

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