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