From: "Phlip" <phlip_cpp / yahoo.com>
>
> Bill Kelly wrote:
> 
> > That is, it's an extra distinction about objects, or object
> > allocation, that languages like Ruby or Java don't have. . .
> > So C++'ers utilize this guaranteed "out of scope destruction"
> > of locally allocated objects to implement things like smart
> > pointers (such as std::auto_ptr<>) which can perform an automatic
> > delete on the type of (heap allocated) object to which they
> > point, as the smart pointer itself (a locally allocated stack
> > frame object) goes out of scope.
> 
> In the light of exception safety, the above must be said the other way 
> around; given the requirement that exceptions roll state back cleanly, the 
> best OO models will take care that their 'ensure' blocks are automatic, and 
> not coupled to the calling code that experienced the exception. So C++ers 
> use destructors, and programmers using languages with garbage collection 
> and blocks use the "Execute Around Method" pattern (from /Smalltalk Best 
> Practice Patterns/, page 37, by Bent Keck).

I HaveThisPattern (and the book :) but one thing that nags at me
about it - although I admit that till now I have not given it more
than passing consideration - is the possible difficulty of applying
this pattern where multiple resources are being used interdependently
at the same level of hierarchy.

Say opening an input file and an output file, reading lines from 
input, applying some transformation, writing them to output. . .
Heh, actually, that's no problem at all is it?

def file_line_xform(inFname, outFname)
  File.open(inFname, File::RDONLY) {|fin|
    File.open(outFname, File::WRONLY|File::CREAT|File::TRUNC) {|fout|
      fin.each_line {|line|
        line = yield(line) if block_given?
        fout.print line
      }
    }
  }
end


Cool.  Well maybe whatever was nagging at me was false...(?)  If I
can come up with an example of it I'll be sure and post though. :-)


> > where is in GC'd languages one need only ensure deterministic
> > cleanup of objects holding non-memory resources.
> 
> If an exception blew away your current context, would your system state 
> roll back completely and cleanly to the point it was at before the 'begin'?

It depends.  I'm pretty fanatic about trying to minimize side-effects
in my code and if a branch in the execution path is rolled back because
of an exception, it's typical I haven't needed to add on much extra
logic to make sure it cleans up after itself.  Still, even that code
above - though it closes files nicely - will leave a partially processed
output file lying around unless we decide it's important to add the code
to clean it up.


Regards,

Bill