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. _______________________________________________ NumPy-Discussion mailing list NumPy-Discussion@python.org https://mail.python.org/mailman/listinfo/numpy-discussion
