[Numpy-discussion] How a transition to C++ could work

David Cournapeau cournape@gmail....
Sun Feb 19 03:45:42 CST 2012

On Sun, Feb 19, 2012 at 9:19 AM, Mark Wiebe <mwwiebe@gmail.com> wrote:
> On Sun, Feb 19, 2012 at 2:56 AM, David Cournapeau <cournape@gmail.com>
> wrote:
>> Hi Mark,
>> thank you for joining this discussion.
>> On Sun, Feb 19, 2012 at 7:18 AM, Mark Wiebe <mwwiebe@gmail.com> wrote:
>> > The suggestion of transitioning the NumPy core code from C to C++ has
>> > sparked a vigorous debate, and I thought I'd start a new thread to give
>> > my
>> > perspective on some of the issues raised, and describe how such a
>> > transition
>> > could occur.
>> >
>> > First, I'd like to reiterate the gcc rationale for their choice to
>> > switch:
>> > http://gcc.gnu.org/wiki/gcc-in-cxx#Rationale
>> >
>> > In particular, these points deserve emphasis:
>> >
>> > The C subset of C++ is just as efficient as C.
>> > C++ supports cleaner code in several significant cases.
>> > C++ makes it easier to write cleaner interfaces by making it harder to
>> > break
>> > interface boundaries.
>> > C++ never requires uglier code.
>> I think those arguments will not be very useful: they are subjective,
>> and unlikely to convince people who prefer C to C++.
> They are arguments from a team which implement both a C and a C++ compiler.
> In the spectrum of possible authorities on the matter, they rate about as
> high as I can imagine.

There are quite a few arguments who are as authoritative and think
those arguments are not very strong. They are as unlikely to change
your mind as the gcc's arguments are unlikely to convince me I am

> This is a necessary part of providing a C API, and is included as a
> requirement of doing that. All C++ libraries which expose a C API deal with
> this.

The only two given examples given so far for a C library around C++
code (clang and zeromq) do not use exceptions. Can you provide an
example of a C++ library that has a C API and does use exception ?

If not, I would like to know the technical details if you don't mind
expanding on them.

>> How can one make sure C++ extensions built
>> by different compilers can work ?
> This is no different from the situation in C. Already in C on Windows, one
> can't build NumPy with a different version of Visual C++ than the one used
> to build CPython.

This is a different situation. On windows, the mismatch between VS is
due to the way win32 has been used by python itself - it could
actually be fixed eventually by python (there are efforts in that
regard). It is not a language issue.

Except for that case, numpy has a pretty good record of allowing
people to mix and match compilers. Using mingw on windows and intel
compilers on linux are the typical cases, but not the only ones.

>> I would
>> expect you would like to use templates for iterators in numpy - you
>> can you make them available to 3rd party extensions without requiring
>> C++.
> Yes, something like the nditer is a good example. From C, it would have to
> retain an API in the current style, but C++ users could gain an
> easier-to-use variant.

Providing an "official" C++ library on top of the current C API would
certainly be nice for people who prefer C++ to C. But this is quite
different from using C++ at the core.

The current way iterators work would be very hard (if at all possible
?) to rewrite in idiomatic in C++ while keeping even API compatibility
with the existing C one. For numpy 2.0, we can somehow relax on this.
If it is not too time consuming, could you show a simplified example
of how it would work to write the iterator in C++ while providing a C
API in the spirit of what we have now ?


More information about the NumPy-Discussion mailing list