---------- Forwarded message ---------
From:
Ethan C <echaroenpitaks@gmail.com>Date: Tue, Sep 3, 2024, 17:03
Subject: Re: GNUstep: Specifying a minimum supported compiler version and using C++17 internally
To: Riccardo Mottola <
riccardo.mottola@libero.it>
On 9/1/24 09:07, Riccardo Mottola wrote:
> 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.
>
>
I also agree with this. It would be nearly impossible to build a non-gcc
and non-clang Objective-C++ compiler, while a non-gcc non-clang
Objective-C compiler would not be significantly harder than making a C
compiler, which many people do as a side project. Additionally, some
people know C but not C++. RAII is not the Objective-C coding style, we
generally use manual retain-release. We implement our own collections
library, so there's not really much reason to move to the C++ STL. I can
see where templating is useful, but that's one of the features that
makes implementing a C++ compiler much harder than implementing a C
compiler. I do agree that the C++ lambda function syntax is better and
easier to understand than blocks (I wish C23 included lambdas like was
proposed, or at least that GCC and Clang included it as a GNU C extension).
>> 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.
> een
Some rather major things were removed, such as Carbon, but yes, I don't
think anything has really been removed from Foundation or AppKit.
However, they do remove deprecated APIs from CoreFoundation sometimes (I
can't think of one off the top of my head, but there are multiple
deprecated CoreFoundation functions that currently throw a
not-implemented-exception and abort the entire program).
>>
>> 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.
Libdispatch does seem like something that is actually valuable. However,
I'm fairly sure it does require block support. The libdispatch
developers are also against changing the build system so that you aren't
forced to build and install the libdispatch-provided blocks runtime, so
at the very least we would want to soft-fork libdispatch and modify its
CMake files so that we can use our own blocks runtime or not have a
blocks runtime at all.