Re: Transitioning libgomp from C to C++ implementation: untyped 'gomp_malloc' etc.

Hi,

Thomas Schwinge wrote:
> So, first item: what do we do with the untyped 'gomp_malloc' etc.?
> 'libgomp/libgomp.h':
>      extern void *gomp_malloc (size_t) __attribute__((malloc));
...
> In other words, we'll need some kind of type casting at each call site:
> I could already in the C implementation make that:
>
>      plock = (gomp_mutex_t *) gomp_malloc (sizeof (gomp_mutex_t));
> ..., or (preferably?):
>      plock = (typeof (plock)) gomp_malloc (sizeof (gomp_mutex_t));

well, while 'typeof' is C23, 'decltype' is C++11 while __typeof__ works
as compiler extension with both GCC's C and C++ compiler.

An alternative to the explicit cast would be what we do inside GCC itself,
namely to use a macro:

libiberty.h:#define XCNEW(T)            ((T *) xcalloc (1, sizeof (T)))
libiberty.h:#define XCNEWVEC(T, N)              ((T *) xcalloc ((N), sizeof (T)))
libiberty.h:#define XCNEWVAR(T, S)              ((T *) xcalloc (1, (S)))

which could be used as is – or with T on the RHS replaced by
__typeof__(T) which then works with both type names and variable names.

> Such changes could go in already now, in the C code.  However, I assume
> that we'd eventually like this to be proper C++:
>
>      plock = static_cast<decltype(plock)>(gomp_malloc (sizeof (gomp_mutex_t)));

I think one can discuss whether '(T)' is also proper C++ or only 'static_cast<T>'.

(the static_case one makes it longer and hence less readable but is more
explicit and C++-ize.)

* * *

> In the external header files ('omp.h', 'openacc.h', etc.), I guess we'll
> just continue to use C-style casts for C/C++ compatibility, or some:
>
>      #ifdef __cplusplus
>      # define STATIC_CAST(T, x) static_cast<T>(x)
>      #else
>      # define STATIC_CAST(T, x) ((T) (x))
>      #endif

Why do you need to touch the external files at all? Those should already
be working with both C and C++? (BTW: There is some C++ only code in omp.h
as std::allocator replacement.)

And for casts, you don't even get something better by using static_cast
via a macro. - I see the argument of using it with explicitly written
code but here?

And when later moving to static_cast<...>(...) as cleanup, you need to
touch all call sides already you might need to adjust indentation anyway.

* * *

For a step-wise conversion, I think either using a macro version, similar
to libiberty.h or using the C-style cast makes sense.

And later, we can still decide whether doing style changes, but I think
this cast is not really the most important change for clarity, type safety
or similar reasons.

Tobias