Should destructors be able to tell who called them?

Steven Schveighoffer schveiguy at yahoo.com
Tue Aug 10 12:07:33 PDT 2010


On Tue, 10 Aug 2010 14:38:13 -0400, Michel Fortin  
<michel.fortin at michelf.com> wrote:

> On 2010-08-10 14:25:48 -0400, "Steven Schveighoffer"  
> <schveiguy at yahoo.com> said:
>
>> ~this(bool deterministic)
>> {
>>     if(deterministic) file.close();
>> }
>>  or like this:
>>  ~this()
>> {
>> }
>>  Scope classes (if allowed to exist) or calls to clear will set   
>> deterministic to true.  The GC will set it to false.
>>  This would make destructors a lot more useful.  Thoughts?
>
> In Objective-C we have the dealloc method (deterministic) and the  
> finalize method (non-deterministic). The former is used in a  
> reference-counted environment while the second is used when memory is  
> managed by a GC.
>
> One issue with having one destructor with a deterministic argument (as  
> opposed to having two separate destructors) is that non-deterministic  
> destructors should probably not be allowed in SafeD because you can then  
> get access to dangling pointers and you can even pass them around to  
> make them live long after the collection has terminated.

Good point.  I'd restate it as should safeD be able to define  
deterministic destructors?  i.e. a solution to this is not to allow  
defining class destructors at all in safeD.  That might be too limiting,  
but not any more limiting than it is now...  I don't know what the right  
answer is.

What I was looking for was a solution that was backwards compatible with  
current code, and one that didn't require you to call __dtor directly.

-Steve


More information about the Digitalmars-d mailing list