Destructor semantics

foobar foo at bar.com
Wed Aug 11 06:53:24 PDT 2010


Steven Schveighoffer Wrote:


> So if a struct has a class reference, it cannot clean it up?  What if the  
> class contains a struct that has an open file reference, and you want to  
> clean up that file immediately?  What if that class is private and the  
> struct knows that there are no other references to it?
> 
> Your "solution" doesn't cover any new ground, we already have the issue  
> that you cannot clean up or even access heap-allocated references in  
> destructors.  The problem is, you don't know from the type system that  
> they are heap-allocated, and the compiler cannot know what is owned and  
> what is not owned, so it can't make the call to restrict you.
> 
> What we need is a way to determine whether we can access those resources  
> or not in the destructor, and it has nothing to do with struct vs. class,  
> and everything to do with deterministic vs GC.  Making an artificial  
> distinction on class/struct lines doesn't help.  We have the same problem,  
> only worse restrictions (now I can't destroy a handle in a class on  
> destruction, I need to put in a struct layer around it).
> 
> -Steve

I see your point above. I feel that my approach is more structured. I think that at minimum the compiler should prevent (at compile time) any access to reference types from a class dtor. 
I can't imagine what can be your use case for allowing such access. It seems to me that any time you feel the need for one class instance to own a different class instance you should use a struct instead to convey that owned relationship.

Wouldn't you need an annotation system like the one suggested by Bartoz in order to properly implement the owned relationship for reference types? 



More information about the Digitalmars-d mailing list