[Interest] [OSX/iOS] Garbage collection still in place in Qt?

[Till Oliver Knoll]

> Am 03.03.2015 um 18:55 schrieb Thiago Macieira <thiago.macieira at intel.com>:
> 
>> ...
>> 
>> So Qt could still support OS X 10.6 and 32 bit, if that was the point of
>> your statement.
> [snip]
>> That said, IIRC official OS X 10.6 support was dropped quite some time ago
>> by Qt, so that would be a non-issue anyway.
> 
> OS X 10.6 is no longer supported. The reason for that is that we dropped the 
> code paths that conflicted with ARC.

What exactly are you saying here? That the deprecated "Garbage Collector" API calls have already been removed and all Qt frameworks (Core, Gui, Widgets, ...) only use manual retain/release memory management?

The reason why I am a bit confused here is that also manual "retain/release" calls actually do conflict with ARC as well, since that's the whole point of ARC: that retain/release calls are placed automatically where applicable and only the necessary calls are left in the final binary (the superfluous calls are optimised away as good as possible during some build step).

So when you say that you "dropped the code paths that conflicted with ARC" that could only mean that Qt would /already/ use ARC.

But that statement would conflict with the following:

> But I haven't heard anything about 32-bit support. I thought that was still 
> working and used ARC.

No. It really seems that ARC is only supported for 64 bit binaries, see e.g. here:

  http://stackoverflow.com/questions/7865423/mac-app-store-giving-up-32-bit-support-in-favor-for-arc-will-existing-users-of




> Unless you meant that the Mac App Store will only accept 
> submissions of 64-bit applications. If that's what you meant, then it doesn't 
> affect us: we should continue to support 32-bit for a while.

So the fact that Qt does still support 32 bit binaries can only mean that Qt is /not/ yet ready for ARC.

From a Mac App Store point of view that's fine, as long as only manual retain/release calls are done.

But everything "Garbage Collection" related (e.g. use of NSGarbageCollector) must be gone as of May 1st 2015 (for Mac App Store applications).

A quick check whether Qt is (still) compiled with enabled Garbage Collection (besides scanning the source code for deprecated API calls) could be to watch out for the following compiler flags during compilation (of *.mm sources):

  -fobjc-gc-only

Or

  -fobjc-gc

The absence of either flag means: "GOOD! Qt is /not/ using GC!"

(https://developer.apple.com/legacy/library/documentation/Cocoa/Conceptual/GarbageCollection/GarbageCollection.pdf)

At least that's my understanding.

And by the way: I think GC never made it into the corresponding iOS APIs (unlike the Subject of this email suggests).


So I have to repeat my question: do we know for sure what the state of Qt is (maybe at least per module, like Core, Gui, Widgets... WebKit might be an entire different beast ;)) with regards to the deprecated Garbage Collection? Work in progress? Not an issue (anymore)? "Let's find out on May 1st 2015"? ;)

Cheers,
  Oliver



> 
>> So the real question remains: does Qt still have some "garbage collection
>> left-overs", and if so, is this being considered and maybe (hopefully) even
>> being work in progress, to either move the Qt libs forward to use ARC
>> (requires some brainwork as soon as you interface Cocoa with the C/C++
>> world: you need to tell the compiler who is responsible to release memory:
>> ARC or "the other side of the bridge (C/C++)"), or at least replace
>> "garbage collection" with explicit retain/release management (requires
>> probably even more brainwork: after all there was a reason to let the
>> "garbage collector" do all the hard work ;))
> 
> -- 
> Thiago Macieira - thiago.macieira (AT) intel.com
>  Software Architect - Intel Open Source Technology Center
> 
> _______________________________________________
> Interest mailing list
> Interest at qt-project.org
> http://lists.qt-project.org/mailman/listinfo/interest