D/Objective-C 64bit

[Michel Fortin via Digitalmars-d-announce]

On 2014-10-30 07:13:08 +0000, Jacob Carlborg <doob at 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 
irrelevant.


> 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).

-- 
Michel Fortin
michel.fortin at michelf.ca
http://michelf.ca