On 08/05/2026 06:38, Martin Uecker via Gcc wrote:
Am Donnerstag, dem 07.05.2026 um 13:16 +0200 schrieb Thomas Schwinge:
Hi!
This is not intended to turn into a "color of the bike shed" discussion,
and also not into a "would additionally be nice to do [...]" discussion.
;-)
The idea of transitioning libgomp from C to C++ implementation has come
up a number of times, where the clunkiness that comes with C++ is
believed to be favorable compared to the clunkiness of the C
implementation.
This was, for example, in contexts such as generally enhancing type
safety, refactoring certain data structures (for various reasons),
potentially making light use of inheritance (for example, in libgomp
plugins),
I am not convinced that moving to C++ actually makes code more
type safe or otherwise better.
I am not working on libgomp, so my opinion may not be important.
But for libraries such libubsan I observe that people created
alternatives in C so having a C version would generally be more
useful.
Martin
I haven't worked on libgomp, but I agree with Martin's points.
A lot of compilers can plausibly support modern C that will never
support modern C++. Modern C offers features for convenience (e.g. auto)
and macro-based polymorphism (e.g. _Generic). Subtype polymorphism is
more limited than in C++ but still achievable with a reasonable degree
of type safety.
The issue with malloc seems to me like a canary in the coal mine. I
don't know whether libgomp makes significant use of callback functions
and event handlers, but they are likely to suffer from similar issues.
If the return type of malloc is perceived to be a problem, then it is
trivial to write a wrapper macro, e.g.
// https://godbolt.org/z/x58s8qMG3
#include <stdlib.h>
#define NEW(T) ((typeof(T) *)malloc(sizeof (T)))
#define NEW_ARRAY(T, N) ((typeof(T) *)malloc(sizeof (T) * (N)))
#define FOR_EACH(IT, AR) for (size_t IT = 0; IT < _Countof (AR); ++IT)
int main(int argc, const char *argv[static argc + 1])
{
auto i = NEW(int [10]);
if (i)
(*i)[1] = 1;
auto j = NEW_ARRAY(int, 10);
if (j)
j[3] = 2;
auto k = NEW_ARRAY(typeof(argv[0]), argc);
if (k)
for (size_t l = 0; l < argc; ++l)
k[l] = argv[l];
auto m = NEW(typeof(argv[0]) [argc]);
if (m)
FOR_EACH(l, *m)
(*m)[l] = argv[l];
free(i);
free(j);
free(k);
free(m);
}
C projects 'upgraded' to C++ can end up worse than reasonable code
written from scratch according to good idioms of either language, due to:
- C++'s overly strict type rules concerning void *. Without care, C++'s
type system has the ironic effect of making code *less* type-safe. (For
the same reason that it would be less type-safe for MyPy to require
explicit conversion of 'Any' to some other type.)
- C++ constructors being unable to return a failure indication, and the
gymnastics required to work around that without using exceptions
(leading to many identically-named construction helpers).
- Erasure of designated initialisers that were vital for keeping the
code readable and maintainable (by preventing definitions, for example
array initialisers and enumerations, from diverging).
- Gratuitous loss of the ability to find method definitions and usages
using simple tools like 'grep'. (I do not mean gratuitous as a
perjorative but in the specific sense that some useful patterns require
subtype polymorphism, in which case the equivalent C code would have the
same issue, but most code does not.)
As I said, I'm not familiar with libgomp, so I have no idea how much it
might benefit in areas where C++ truly does excel, such as object
lifetime management. In my experience, few C projects have complex
object lifetimes (by design), but maybe libgomp is one of them.
Lastly, some C programmers are put off contributing to C++ codebases. I
don't know how common the converse is.
Ultimately, it's up to the maintainers to decide. Good luck!
--
Christopher Bazley
Staff Software Engineer, GNU Tools Team.
Arm Ltd, 110 Fulbourn Road, Cambridge, CB1 9NJ, UK.
http://www.arm.com/
