auto classes and finalizers ~ dtor means RAII ?
kris
foo at bar.com
Thu Apr 6 00:28:43 PDT 2006
Mike Capp wrote:
> In article <e10pk7$2khb$1 at digitaldaemon.com>, Sean Kelly says...
>
>>I've been following a thread on GC in c.l.c++.m and something Herb
>>posted about C++/CLI today got me thinking:
>>
>> - a type can have a destructor and/or a finalizer
>> - the destructor is called upon a) explicit delete or b) at end
>> of scope for auto objects
>> - the finalizer is called if allocated on the gc heap and the
>> destructor has not been called
>>[snip]
>>Might it not be worthwhile to do something similar to the above? This
>>would allow objects to explicitly delete all their contained data in
>>instances where they are being used as auto objects, rather than always
>>relying on the GC for this purpose. I'll admit I don't particularly
>>like the idea of separate finalize() and ~this() methods, but it seems
>>an attractive enough feature that something along these lines may be
>>appropriate.
>
>
> Personally I'm against it. I feel quite strongly that defining a destructor (or
> finalizer) should be illegal for a GC type - it should only be allowed for a
> class declared as 'auto'. If you need dtor-like behaviour, you should not be
> using GC, and the compiler should tell you so.
>
> I posted this opinion some weeks back in a similar discussion here, expecting to
> be chased out of town with pitchforks, but the response was very positive.
> Nobody could think of any counterexamples, at any rate.
>
> cheers
> Mike
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?
Thus, any class with a dtor is automatically RAII. When the dtor is
actually invoked, all relevant GC allocations should still be intact; yes?
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.
Thoughts?
- Kris
More information about the Digitalmars-d
mailing list