[Numpy-discussion] A bite of C++

[Serge Guelton]

On Wed, Aug 25, 2021 at 05:50:49PM -0500, Sebastian Berg 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.
> > 
> > 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.

Hi Sebastian and thanks for the feedback.


> I am not a C++ export, and really have to get to used to this code.  So
> I would prefer if some C++ experts can look at it and give feedback.

I don't know if I'm a C++ expert, but I've a decent background with that
language. I'll try to give as much clarification as I can.

> This will be a bit harder to read for me than our `.c.src` code for a
> while.  But on the up-side, I am frustrated by my IDE not being able to
> deal with the `c.src` templating.

> One reaction reading the X-macro trick is that I would be more
> comfortable with a positive list rather than block-listing.  It just
> felt a bit like too much magic and I am not sure how good it is to
> assume we usually want to export everything (for one, datetimes are
> pretty special).
> 
> Even if it is verbose, I would not mind if we just list everything, so
> long we have short-hands for all-integers, all-float, all-inexact, etc.

There has been similar comments on the PR, I've reverted to an explicit listing.

> > 
> > Some changes in distutils were needed to cope with C++-specific
> > flags, and
> > extensions that consist in mixed C and C++ code.
> 
> <snip>
> 
> > Potential follow-ups :
> > 
> > - do we want to use -nostdlib, to be sure we don't bring any C++
> > runtime dep?
> 
> What does this mean for compatibility?  It sounds reasonable to me for
> now if it increases systems we can run on, but I really don't know.

It basically means less packaging issues as one doesn't need to link with the
standard C++ library. It doesn't prevent from using some headers, but remove
some aspect of the language. If numpy wants to use C++ as a preprocessor on
steorids, that's fine. If Numpy wants to embrace more of C++, it's a bad idea
(e.g. no new operator)

> > - what about -fno-exception, -fno-rtti?
> 
> How do C++ exceptions work at run-time?  What if I store a C++ function
> pointer that raises an exception and use it from a C program?  Does it
> add run-time overhead, do we need that `no-exception` to define that
> our functions are actually C "calling convention" in this regard?!

Exception add runtime overhead and imply larger binaries. If an exception is
raised at C++ level and not caught at C++ level, there going to unwind the whole
C stack and then call a default handler that terminates the program.

> Run-time calling convention changes worry me, because I am not sure C++
> exception have a place in the current or even future ABI.  All our
> current API use a `-1` return value for exceptions.
> 
> This is just like Python's type slots, so there must be "off the
> shelve" approaches for this?
> 
> Embracing C++ exceptions seems a bit steep to me right now, unless I am
> missing something awesome?

I totally second your opinion. In the spirit of C++ as a preprocessor
on steroids, I don't see why exception would be needed.

> I will note that a lot of the functions that we want to template like
> this, are – and should be – accessible as public API (i.e. you can ask
> NumPy to give you the function pointer).

As of now, I've kept the current C symbol names, which requires a thin foward to
the C++ implementation. I would be glad to remove those, but I think it's a nice
second step, something that could be done once the custom preprocessor has been
removed.