auto classes and finalizers ~ dtor means RAII ?

[Regan Heath]

On Thu, 06 Apr 2006 11:48:07 -0700, kris <foo at bar.com> wrote:
> Mike Capp wrote:
>>> 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.

I did, I also suggested some solutions:
http://www.digitalmars.com/drn-bin/wwwnews?digitalmars.D/36462

- refrence counting.
- a new 'shared' keyword.

The idea in that thread (isn't really a new idea) is essentially what Kris  
said above:
>>> 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?

In my case; removal of 'auto' from object instance declaration, but  
requiring it on class definitions when a dtor is present. Plus requiring  
it on classes containing classes which are 'auto'.

After all a dtor indicates some (non-memory) cleanup needs to be done,  
making it RAII be definition, no? And any class containing a reference  
that needs cleanup, will itself need cleanup, right?

I think we need to try and come up with some examples of where it can't  
work, and/or decide what the limitations are and if they're an  
inappropriate cost to pay for what I think could be quite a safe system to  
write RAII in.

You said:
>>   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.

IMO the benefit outweights this cost. Much like it does for 'out' etc  
function parameters.

Regan