auto classes and finalizers ~ dtor means RAII ?

[kris]

Mike Capp wrote:
> In article <e12fva$29gr$1 at digitaldaemon.com>, kris says...
> 
>>Mike;
>>
>>Instead of making the dtor illegal for GC types, why not remove the 
>>'auto' keyword from this realm altogether, and just use the existance of 
>>a dtor as the class RAII indicator?
> 
> 
> The trouble is that this wouldn't make the RAII behaviour apparent to somebody
> reading the code. They'd have to go and look at the class definition. I'm happy
> to do a little extra typing for the sake of code clarity here, in the same way
> that I thought C#'s insistence on having "in" and "ref" arguments marked as such
> by calls as well as decls was a nice touch.

Yes, that is true.



>>What to do about those classes that need a dtor-like construct, but 
>>cannot be deemed RAII? Be explicit about closing them, using the close() 
>>or dispose() approach.
> 
> 
> Can you give some concrete examples of such 'awkward' classes? I'm not saying
> they don't exist, but I'm not assuming that they must, either. 

Well, pretty much anything intended to be long-lived within the program, 
yet the OS cannot clean up by default. This includes external hardware 
which should be reset or otherwise released and, more commonly, various 
types of scant resources used for purposes of optimization ~ Regan noted 
database resources, which are a good example. Others might include 
termination network-handshaking, and so on. Such things are often 
wrapped via a class, with the expectation said class can encapsulate the 
cleanup process. Their scope (or life expectancy) is often intended to 
span a considerable period of time.

In some cases it might be possible to arrange the code such that these 
entities are actually scoped on the stack (for RAII purposes), where the 
enclosing function doesn't exit until termination time. However, others 
often have a life expectancy based upon "activity" ~ a classic example 
might be cached database resources, where life-expectancy of the object 
has nothing to do with scope per se, but is instead often based upon a 
period of dormancy or inactivity.



> The "dispose"
> (anti-)pattern is, frankly, awful. It's "Wrong By Default" taken to the extreme.

This is the option left open after the discovery that dtor() is pretty 
much worthless. I agree that a better solution is needed.