On 2014-10-30 07:13:08 +0000, Jacob Carlborg <d...@me.com> said:
I had a look at your fix. I see that you added a call to "release" in
the destructor. Just for the record, there's no guarantee that the
destructor of a GC allocated object gets run, at all.
D/Objective-C never allocates Objective-C objects on the GC heap. If an
object derives from NSObject it is allocated using the usual
Objective-C alloc class method when you use the "new" keyword.
Or, if this class get instantiated by some Objective-C framework then
it will know nothing about the destructor in D. I guess the right
solution is to override "dealloc".
Whoever instantiated the object has no bearing on who will deallocate
and call its destructor. When you call release() and the counter falls
to zero, "dealloc" is called and the memory is then released. Whether
that call to release() was made from D or Objective-C code is
Hmm, I'm wondering if it's a good idea to lower a destructor to
"dealloc", just like a constructor is lowered to "init".
I can't remember if this is an oversight or just something that I
hadn't got to yet. In my mind this was already done.
Anyway, the answer is *yes*: the destructor should be mapped to the
"dealloc" selector. It should also implicitly call the destructor for
any struct within the object and call it's superclass's destructor (if
present), the usual D semantics for a destructor (that part might
already work actually).