https://developer.apple.com/news/?id=02202015a
Name it great foresight of Geoff Perlman, or just a lucky punch, but it looks like Xojo user are now on the safe side already:
Xojo uses reference counting, not garbage collection.
http://www.realsoftwareblog.com/2011/01/managing-your-memory.html
Oh - there is another thread already. Sorry about that.
Only true for Xojo objects. Not true for Objective C objects. ARC on Cocoa is only available for 64bit-compiles. Xojo still compiles to 32bit.
Xojo uses manual, explicit reference counting. This is just fine for the MAS. Already confirmed by Joe Ranieri at https://forum.xojo.com/20216-arc-memory-management/p1#p169675
Are you really sure about this? Despite for some core objects like CIFilter, I use own implementations of Mac OS X controls for a long time without any retain and release, just pinning their init ptr to a Xojo Ptr. No problems at all.
You’re almost certainly leaking memory if you never release the object.
This is really funny. I ran some tests on NSNumber. For Booleans, absolutely no memoryleak creating and abandoning 300.000 in a loop raised the memory by 0.1 MB which were released too after a few seconds. The same for doubles.
For Integers, but basically the same structure, heavy memory leaks. ??!!??
When I insert a release into NSNumber’s destructor, regardless of the type and without having called retain, everything works fine and no memory loss anymore. When I do so with NSObject destructor, the app crashes.
Hmm. Seems I have to fine-tune the classes but wonder why it works for some types and not for others.
How do you create the NSNumber?
It’s a subclass of a NSObject class using several polymorphed constructors to pass the result of the designated init to the base class’ id ptr. In other words:
Sub Constructor(aBool as boolean)
#if targetmacos
declare function initWithBool lib AppKit Selector "initWithBool:" (id as ptr, aBool as boolean) as ptr
super.constructor (initWithBool (Alloc(ClassPtr), aBool))
#endif
End Sub
for Booleans (no memory leak) or
Sub Constructor(anint as Integer)
#if targetmacos
declare function initWithInteger lib AppKit Selector "initWithInteger:" (id as ptr, anint as integer) as ptr
super.constructor ( initWithInteger (Alloc(ClassPtr), anint))
#endif
End Sub
for Integers (heavy memory leak without destructor).
ClassPtr is of course NSClassFromString (“NSNumber”). Do you have any ideas why they behave so differently?
The only difference in their appearance is I have to pass an Integer to the constructor so the correct constructor is chosen while Booleans or Doubles work directly without having to use a property. But it’s not the property that makes the memory hunger.
EDIT: I forgot: And the NSObject (superclass) constructor for a Ptr is simply
Sub Constructor(id as Ptr)
mid = id
End Sub
I have traced the NSObject desctructor crash to a XojWindow that gets deallocated and doesn’t like to get a release call. Which is very funny because I do not close any window at that time
At least I don’t remember
Looks like I have to dig a bit more into this.
In my NSNumber implementation I use:
declare function initWithInt lib AppKit Selector "initWithInt:" (id as ptr, anint as int32) as ptrTried it, but doesn’t change the situation. But as the other types that didn’t cause memory leak without release don’t crash when I release them in the destructor too, this seems to be workable. Though I still wonder why there is that difference in behavior.
Is a Xojo PopupMenu a subclass of a XojWindow? That’s the only thing that gets closed when I analyze the NSObject destructor on the crashing method where it shows me that a XojWindow gets released. Very strange because I have several popups and only one gets caught or seems to get caught by the destructor. And I didn’t subclass Popupmenus which leaves me puzzled why it gets caught at all.
From http://cocoadev.com/RulesOfThumb:
If you alloc, retain, or copy it, it’s your job to release it. Otherwise it isn’t.
If you alloc, retain, or copy it, it’s your job to release it. Otherwise it isn’t. Yes: read this again!
If you alloc, retain, or copy it, it’s your job to release it. Otherwise it isn’t. Twice is not enough for this rule, read it again!
[quote=169908:@Eli Ott]From http://cocoadev.com/RulesOfThumb:
If you alloc, retain, or copy it, it’s your job to release it. Otherwise it isn’t.
If you alloc, retain, or copy it, it’s your job to release it. Otherwise it isn’t. Yes: read this again!
If you alloc, retain, or copy it, it’s your job to release it. Otherwise it isn’t. Twice is not enough for this rule, read it again![/quote]
Also, if you intend to hold onto the reference in something like a property, you have to retain it and later release it when you’re done with it.
Thanks a lot, Eli! I was only aware of the middle part 
I still don’t know why I catch the XojWindow destructor but then it would be a solution to call a release only if it’s part of an own class, not a Xoj one.
Yes, I’ve read that often, but I experimented with this for a long time and only found the classes Apple explicitely tells you to retain manually like CIFIlter to be instable. In all other cases of several visible and invisible OS X controls I found they always have a retain count of 1 (I know that’s not reliable, but it’s a positive number <> 0) and never vanished until I released the ptr I attached them too.
I don’t want to question your words. It’s just that I couldn’t verify this rule in experiment.
Anyway, releasing obviously is important, and may it only be for the sake of those (sub)types who behave differently, like the Integer NSNumber. For the others, it seems it doesn’t hurt them. Thanks a lot for that!
No edit possible, ok.
Eli, in your link (brilliant! Thanks again!) I found this:
As I do so with them, that seems to be the reason I don’t have to cast an extra retain on them to keep them alive.
CIFIlter is created by a filterWithName method, not alloc (init). That’s why I found I need a retain in that case.