Re: GNUstep: Specifying a minimum supported compiler version and using C++17 internally

[Riccardo Mottola]

Hi,


Hugo Melder wrote:
> Hey,
>
> I’ve looked into the coding guidelines of libs-base and have not found 
> a mention of a minimum supported compiler version.
> This means there are no real guarantees on the C language version and 
> a memory model whatsoever.
> Starting with C11/C++11 we converged to SC-DRF and now have built-in 
> atomic operations and overall better guarantees due to codification of 
> a memory model.
>
> This would avoid doing UB such as using plain ints for gsrefcount_t 
> without even issuing a warning 
> (https://github.com/gnustep/libs-base/blob/7474bd80e3f4611ad52a2b76e85d39f60ea956dd/Source/NSObject.m#L385).
> There are other instances of workarounds and hacks for archaic GCC 
> versions. Platform-dependent atomic operations for object reference 
> counting is currently implemented in inline assembly. We should remove 
> the responsibility of generating correct instructions to the compiler 
> and use the C11/C++11 atomics instead.
>
> My proposal is to bump the minimum supported GCC version to GCC 9.x 
> which is the supported version in RHEL8. When enforcing this minimum 
> version of GCC, we can focus on writing C17 (GCC 8.x or later).  For 
> the libobjc2-based toolchain, any recent clang version (16 or later) 
> will do. Background for this is that older clang versions had serious 
> bugs when targeting MSVC.

Right now GNUstep is currently very portable because it supports 
"archaic" GCC. Not just GCC, I mean GCC 4.x and I stand for that.
But further, C++ is not needed at all to build GNUstep, I just did a 
compile on Linux the other day on a system without C++ and everything 
worked.

> Using C++ in the Codebase
>
> I am aware that this is a disruptive proposal but I’d really like to 
> see modern C++ in our codebase. Compared to the more conservative C 
> STL, the C++ STL is fast and really feature rich. Just take a look at 
> std::transform, std::reduce, for potentially parallel operations, or 
> the wrapped pointer objects. It is generally safer to use RAII then to 
> juggle with bare new and deletes (or mallocs if you will). We can also 
> utilise some templating to reduce the boilerplate in KVO and other 
> instances when we need to parameterise a function (KVO because of the 
> type encoding cases). Who needs Objective-C blocks if we have lambda 
> functions ;)
>
> As we are only exporting ObjC, this would not impact ABI stability.

More than compiler version, I am very much against requiring C++ for 
GNUstep! and from that actually follows that probably there is no need 
to raise C++ requirements.


> Proper API Deprecation Policy
>
> Apple deprecated a lot of functions and classes in recent years. Are 
> we going to do the same? Should we remove them after at least two 
> major GNUstep releases?

I think we never removed anything - except some workarounds or plain 
incompatibilities - but to be honest from what I know, neither Apple 
does. They remove it from headers perhaps, but nothing really went away.

> Make Grand Central Dispatch a first Citizen
>
> Libdispatch is really great. Apple spent a lot of time and money 
> refactoring their internal codebase to use libdispatch instead of 
> lower level pthreads or NSThreads. We should do the same and make 
> libdispatch mandatory for the Foundation library. This will result in 
> more efficient resource usage and a better concurrency “model” than 
> what we have now. You can compile libdispatch without block support 
> and use it with GCC. The only problem is the absence of a libdispatch 
> package in the Debian and Ubuntu repositories.

libdispatch is mainly C and doesn't require C++ right? I am unsure about 
using this as a strict requirement though. I read about portbaility 
issues and found issues myself, then lost interest in it, but that was 
quite some time ago. There was a transition to swift core library.
However it requires blocks and I wonder how this works with gcc and g++ 
at the end. Windows was problematic.
I'm not informed enough on all these changes and implications to have an 
good opinion.

Probably this is worth a separate discussion than C++.

Riccardo