[Numpy-discussion] Re: A bite of C++

On Wed, 2021-08-25 at 17:48 +0200, Serge Guelton wrote:

Hi folks,

https://github.com/numpy/numpy/pull/19713 showcases what *could* be a first step toward getting rid of generated C code within numpy, in favor of some C++ code, coupled with a single macro trick.

It seems time to pick up this discussion again. I think we were cautiously in favor of trying this out in the limited proposed form. Aside from ensuring we do not use C++ exceptions/run-time environment. I.e. compile with `-fno-exception` and `-nostdlib`, the PR is probably largely ready. Are there any other bigger issues that need to be discussed? The goal for now seems to allow this type of function templates (C++ as a glorified templating language). We may be able to enforce this with clang-tidy (not sure if that is necessary right away though). There are parts of NumPy (mainly `fft`) where more C++ features could be helpful but that should probably be discussed separately. The current solution ends up using no X-Macro anymore, which means listing the C symbols like: NPY_NO_EXPORT int radixsort_byte(void* vec, npy_intp cnt, void *NPY_UNUSED(null)) { return radixsort(vec, cnt); } NPY_NO_EXPORT int radixsort_ubyte(void* vec, npy_intp cnt, void *NPY_UNUSED(null)) { return radixsort(vec, cnt); } NPY_NO_EXPORT int radixsort_short(void* vec, npy_intp cnt, void *NPY_UNUSED(null)) { return radixsort(vec, cnt); } NPY_NO_EXPORT int radixsort_ushort(void* vec, npy_intp cnt, void *NPY_UNUSED(null)) { return radixsort(vec, cnt); } NPY_NO_EXPORT int radixsort_int(void* vec, npy_intp cnt, void *NPY_UNUSED(null)) { return radixsort(vec, cnt); } NPY_NO_EXPORT int radixsort_uint(void* vec, npy_intp cnt, void *NPY_UNUSED(null)) { return radixsort(vec, cnt); } NPY_NO_EXPORT int radixsort_long(void* vec, npy_intp cnt, void *NPY_UNUSED(null)) { return radixsort(vec, cnt); } NPY_NO_EXPORT int radixsort_ulong(void* vec, npy_intp cnt, void *NPY_UNUSED(null)) { return radixsort(vec, cnt); } I guess we could try to write some macro's to make this shorter, although I am fine with delaying this, since the main point is probably getting a brief example and the build changes in. It also defines the following type tags: https://github.com/numpy/numpy/pull/19713/files#diff-4de4beaecd7b0a1f4d88722... Any comments to the approach (especially from anyone more familiar with C++) would be much appreciated! Cheers, Sebastian

Basically, templated code is an easy and robust way to replace generated code (the C++ compiler becomes the code generator when instantiating code), and a single X-macro takes care of the glue with the C world.

Some changes in distutils were needed to cope with C++-specific flags, and extensions that consist in mixed C and C++ code.

I've kept the change as minimal as possible to ease the (potential) transition and keep the C++ code close to the C code. This led to less idiomatic C++ code, but I value a "correct first" approach. There's an on-going effort by seiko2plus to remove that C layer, I acknowledge this would bring even more C++ code, but that looks orthogonal to me (and a very good second step!)

All lights are green for the PR, let's assume it's a solid ground for discussion :-) So, well, what do you think? Should we go forward?

Potential follow-ups :

- do we want to use -nostdlib, to be sure we don't bring any C++ runtime dep? - what about -fno-exception, -fno-rtti? - coding style? - (I'm-not-a-farseer-I-don-t-know-all-topics)

_______________________________________________ NumPy-Discussion mailing list NumPy-Discussion@python.org https://mail.python.org/mailman/listinfo/numpy-discussion