Path: utzoo!utgpu!news-server.csri.toronto.edu!rutgers!apple!fernwood!lia!jgro From: jgro@lia (Jeremy Grodberg) Newsgroups: comp.std.c++ Subject: Re: Order of destructor calls for auto objects Message-ID: <1991Jan1.015110.329@lia> Date: 1 Jan 91 01:51:10 GMT References: <1990Dec14.221247.9487@lia> <1990Dec20.074232.9416@lth.se> <1990Dec21.192649.1100@sjsumcs.sjsu.edu> Reply-To: jgro@lia.com (Jeremy Grodberg) Lines: 54 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