On Wed, 2021-08-25 at 17:50 -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.


A brief update on this:  The current plan would be to include this in
the next release.  Largely as a trial balloon, so we see if there are
any issues, e.g. with deployment, and can revert the changes if there
are.

That would mean that some time within the next release cycle using C++
for more things could be on the table and less difficult to discuss.

Not knowing the C++ much myself, I assume that the current approach is
fine and the only remaining thing is a brief review of the new code to
ensure correct translation from C.  (Which does not preclude refining
the C++ code later.)

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.
>
> 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.
>
> 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.
>
>
> >
> > 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.
>
> > - 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?!
>
> 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 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).
>
> Cheers,
>
> Sebastian
>
>
> > - 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
> https://mail.python.org/mailman/listinfo/numpy-discussion

_______________________________________________
NumPy-Discussion mailing list -- numpy-discussion@python.org
To unsubscribe send an email to numpy-discussion-leave@python.org
https://mail.python.org/mailman3/lists/numpy-discussion.python.org/
Member address: jbrockmendel@gmail.com