A couple of questions from a quick casual reading 1. radixsort (void *start...) Do we really need void*? We don't know the type of start at compile time?
2. reinterpret_cast<T*> start (related to #1). 3. reinterpret_cast<T*>(malloc(num * sizeof(T))); A C-ism. Would it work to use new T[num]? On Tue, Sep 28, 2021 at 10:03 PM Sebastian Berg <sebast...@sipsolutions.net> wrote: > > 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<npy_byte>(vec, cnt); } > NPY_NO_EXPORT int radixsort_ubyte(void* vec, npy_intp cnt, void > *NPY_UNUSED(null)) { return radixsort<npy_ubyte>(vec, cnt); } > NPY_NO_EXPORT int radixsort_short(void* vec, npy_intp cnt, void > *NPY_UNUSED(null)) { return radixsort<npy_short>(vec, cnt); } > NPY_NO_EXPORT int radixsort_ushort(void* vec, npy_intp cnt, void > *NPY_UNUSED(null)) { return radixsort<npy_ushort>(vec, cnt); } > NPY_NO_EXPORT int radixsort_int(void* vec, npy_intp cnt, void > *NPY_UNUSED(null)) { return radixsort<npy_int>(vec, cnt); } > NPY_NO_EXPORT int radixsort_uint(void* vec, npy_intp cnt, void > *NPY_UNUSED(null)) { return radixsort<npy_uint>(vec, cnt); } > NPY_NO_EXPORT int radixsort_long(void* vec, npy_intp cnt, void > *NPY_UNUSED(null)) { return radixsort<npy_long>(vec, cnt); } > NPY_NO_EXPORT int radixsort_ulong(void* vec, npy_intp cnt, void > *NPY_UNUSED(null)) { return radixsort<npy_ulong>(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-4de4beaecd7b0a1f4d887221191843a54b0c62f13eea18b8716c54bec9657f20 > > 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 > > > > _______________________________________________ > NumPy-Discussion mailing list -- numpy-discussion@python.org > To unsubscribe send an email to numpy-discussion-le...@python.org > https://mail.python.org/mailman3/lists/numpy-discussion.python.org/ > Member address: ndbeck...@gmail.com -- Those who don't understand recursion are doomed to repeat it _______________________________________________ NumPy-Discussion mailing list -- numpy-discussion@python.org To unsubscribe send an email to numpy-discussion-le...@python.org https://mail.python.org/mailman3/lists/numpy-discussion.python.org/ Member address: arch...@mail-archive.com
