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
