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

[Sorvig Morten]

Looks like Thiago is mis-remembering some of the discussion here, I’ll try to clear things up a bit. The following should apply to all of Qt, with the exception of QtWebKit and QtWebEngine which follow the rules set by the upstream projects.

GC: Qt does not use the Cocoa garbage collector, and never have.

ARC: Qt does not use ARC because it's not supported for 32-bit builds. It’s not supported on 10.6 either, which is why the topic was brought up when we dropped support for 10.6.

This does not prevent applications from using ARC since it can be enabled per translation unit. We would like to start using ARC internally in Qt as well, but the requirement to drop 32-bit support may be too steep at this point in time. (Question for interest@: is 32-bit support important?)

Carbon: Qt links against the Carbon framework and uses some functions still available in 64-bit mode. Using the Carbon headers as the authoritative source, these are not deprecated. One example is GetCurrentEventKeyModifiers().

Use of Deprecated API in general: Qt currently uses some deprecated Cocoa API (NSInputManager is one example). If this becomes a problem for app store deployment then it’s something we would like to fix sooner rather than later.

- Morten

> On 04 Mar 2015, at 04:34, Thiago Macieira <thiago.macieira at intel.com> wrote:
> 
> On Tuesday 03 March 2015 23:45:39 Till Oliver Knoll wrote:
>>> 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?
> 
> I am saying that we dropped 10.6 because we began using ARC.
> 
> That doesn't mean we're using ARC everywhere. It just means we're using it 
> somewhere unconditionally.
> 
>> 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:
> 
> "I haven't heard anything about 32-bit support"
> 
> I've never built 32-bit OS X binaries in Qt 5. Unlike Qt 4, Qt 5 does not do 
> universal binaries by default, so it's entirely possible no one has tested 32-
> bit builds in quite a while.
> 
>>> 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.
> 
> I didn't say that. I said I didn't know about 32-bit support. It may be that 
> they no longer work either.
> 
> I also did not say we are ARC-ready. I said only that we are using it in some 
> places.
> 
>> 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
> 
> Neither occurs anywhere in the source code, in any modules. I've checked the 
> 5.5 branch as well as the v5.0.2 tag.
> 
>> 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"? ;)
> 
> I'm pretty sure the answer is "we don't know for sure".
> 
> if this is important, someone should investigate.
> 
> (it's not important to me)
> 
> -- 
> 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