Re: Transitioning libgomp from C to C++ implementation

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/