auto classes and finalizers ~ dtor means RAII ?

[Daniel Keep]

Where to attach this post... aah well, this seems as good a spot as any,
I guess...

I won't pretend I'm an expert in these things, but it seems to me that
adding reference counting to D's wide range of memory management options
would solve most of these problems, yes?

The main case for keeping dtors with GCed objects is that sometimes you
have an object that needs to be cleaned up in some fashion, but which
isn't (or can't easily be) tied to a particular stack frame.  If you
made this class reference counted, then it would be cleaned up the
second the last reference goes out of scope.

The common drawback is the argument that you then have to watch out for
cycles, but Python seems to be coping fine--it has a generational cycle
checker as far as I understand it, and I've seen papers for creating
thread-safe generational checkers so that wouldn't need to be a problem.

I think having lazy GC, RAII, manual memory management and ref. counting
would cover just about everything you could possibly want to do.

Plus, it'd be a great gloating point: "D: memory management YOUR way!"

	-- Daniel

P.S.  I beg forgiveness if I've oversimplified this.

Regan Heath wrote:
> 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

-- 

v1sw5+8Yhw5ln4+5pr6OFma8u6+7Lw4Tm6+7l6+7D
a2Xs3MSr2e4/6+7t4TNSMb6HTOp5en5g6RAHCP    http://hackerkey.com/