[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: Which ObjC2.0 features are missing in the latest GCC?

From: David Chisnall
Subject: Re: Which ObjC2.0 features are missing in the latest GCC?
Date: Wed, 20 Nov 2019 10:52:36 +0000
User-agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:68.0) Gecko/20100101 Thunderbird/68.2.2

On 19/11/2019 23:28, Ivan Vučica wrote:
On Tue, Nov 19, 2019 at 5:26 PM Jordan Schidlowsky <address@hidden <mailto:address@hidden>> wrote: > Is this not the strongest argument to deprecate GCC, and just build on Clang/LLVM?  If feature parity with Apple's API is the goal, isn't this kind of a requirement at this point?
> There's other rather large projects moving purely to a llvm toolchain (android ndk), so it wouldn't be totally unheard of.  They've deprecated gcc and are removing it entirely in a future release.

Multiple compilers is still a good thing (even if one of them is worse than the others).

I agree in theory, but in effect the two compilers support entirely different languages. The jump from the dialect of Objective-C that gcc supports to the dialect that Clang supports is similar in terms of user experience to the jump from C++98 to C++11. All of the C++ projects that I work on have now switched (or are in the process of switching) to depending on C++17, because it's a significant productivity boost.

Supporting GCC is not free. It adds cost to every single GNUstep commit. You have to think about memory management, not just simple ownership rules. You have to use macros instead of core language features (such as fast enumeration). You can't use weak pointers. You can't use blocks.

If GNUstep had a large army of developers, I'd have no objections to this. At the moment, GNUstep is severely under-resourced and time spent supporting GCC is time not spent getting the core libraries up to parity with a vaguely recent version of macOS.

GCC users can accept that not all applications will be compatible, if we can't implement APIs that depend on the "new" features.

Again, GCC users are not the only ones that are paying the cost. I did a run with the ARC migration tool a while ago and around 2/3 of the GNUstep source files could be automatically migrated, many of the remainder needed only minor tweaks. Using modern Objective-C++ in the core of GNUstep could significantly improve productivity. For example, GSIMap is an implementation of a hash table using C macros. It is very difficult to modify (I think I have broken something every time that I've tried). Replacing this with a C++ template would be fairly simple and would make it much easier to switch to other implementations as required (there are a bunch of well-optimised C++ hash table implementations with compatible interfaces tailored to different uses, we could just pull half a dozen of them into the codebase and use them, complete with type safety rather than a load of casts through void*) Oh, and with ARC, all of the C++ implementations have correct memory management for Objective-C, for free.

But perhaps dropping GCC fully is too drastic.

I have a similar opinion about some GUI backends; they're not very useful, but guide gnustep-gui and gnustep-back APIs to be more flexible and don't depend on just e.g. Cairo.

Again, this comes at a cost. For a long time (I'm not sure if this is fixed now), Cairo was slow and flickery because it was being forced to go via a double-buffering mechanism that was designed for libart. Removing this without breaking the xlib and art back ends was nontrivial.

Even today, I believe the Cairo back end is still using the 'toy' font APIs and not the ones that integrate with Harfbuzz, so we get quite poor kerning with Cairo and miss some important features.


reply via email to

[Prev in Thread] Current Thread [Next in Thread]