[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: Gregory Casamento
Subject: Re: Which ObjC2.0 features are missing in the latest GCC?
Date: Thu, 21 Nov 2019 06:15:49 -0500

David et al, 

For all of the reasons listed in the previous email I am starting to wonder about the viability of using GCC in the long run.  As far as I can see it the facts are these:

1. GCC does not support ARC, blocks and many other features which the API is now using 
2. Supporting GCC consumes more time due to having to work around these features using awkward macros
3. The further clang's implementation and gcc's implementation of the language drift apart, the more macros we will need to add
4. The work needed to add these features is monumental
5. We cannot depend on the GCC team to add these as they are more focused on languages outside of ObjC.

The advantages to dropping GCC are as follows:

1. We can simplify the code drastically by removing any and all macros to abstract the missing features 
2. We can switch to using faster C++ or ObjC++ implementations of certain functionality.  TBD further.
3. We get ARC memory management for free.
4. Speeds up development since less time is spent on managing some of the above.

Disadvantages to dropping GCC:

1. Political backlash from the FSF (possible, but unlikely there are projects which use languages not supported by GCC)
2. Not able to support older hardware on which clang is unavailable and gcc still is.
    * We need to assess how critical supporting that hardware is.
3. Altering our "NetBSD" like philosophy where we can say "Of course GNUstep will build on it."

Right now these lists are just food for thought.   I am trying to start a discussion about this, not making any final decisions yet.

Yours, GC

On Thu, Nov 21, 2019 at 6:02 AM Gregory Casamento <address@hidden> wrote:


On Wed, Nov 20, 2019 at 5:54 AM David Chisnall <address@hidden> wrote:
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.

In addition to this fact, the API is becoming more and more dependent on blocks.  Which means that, eventually, the GCC kludges which, at least, keep things compiling will no longer be able to support any of the more recent functionality.   In my recent efforts to get Foundation/base closer to the existing version on Catalina this has become especially apparent.

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.

Again, this is correct.  If I were to estimate, out of the 6-8 weeks it took me to update libs-base, I spect about a total of 3 days figuring out issues related to blocks and how to declare them so that they would compile on gcc (using the macros we have) and work on clang.

Essentially what we have done is abstracted those features that are not supported on gcc so that they are compiled out in that case.

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

Yes, indeed.  Something we don't have with GCC at all.

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



Yours, GC

Gregory Casamento
GNUstep Lead Developer / OLC, Principal Consultant
http://www.gnustep.org - http://heronsperch.blogspot.com

Gregory Casamento
GNUstep Lead Developer / OLC, Principal Consultant
http://www.gnustep.org - http://heronsperch.blogspot.com

reply via email to

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