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

[David Cournapeau]

On Sun, Feb 19, 2012 at 9:52 AM, Mark Wiebe <mwwiebe at gmail.com> wrote:
> On Sun, Feb 19, 2012 at 3:10 AM, Ben Walsh <ben_w_123 at yahoo.co.uk> wrote:
>>
>>
>>
>> > Date: Sun, 19 Feb 2012 01:18:20 -0600
>> > From: Mark Wiebe <mwwiebe at gmail.com>
>> > Subject: [Numpy-discussion] How a transition to C++ could work
>> > To: Discussion of Numerical Python <NumPy-Discussion at scipy.org>
>> > Message-ID:
>> >
>> > <CAMRnEmpVTmt=KduRpZKtgUi516oQtqD4vAzm746HmpqgpFXNqQ at mail.gmail.com>
>> > Content-Type: text/plain; charset="utf-8"
>> >
>> > 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 they're trying to solve a different problem.
>>
>> I thought the problem that numpy was trying to solve is "make inner loops
>> of numerical algorithms very fast". C is great for this because you can
>> write C code and picture precisely what assembly code will be generated.
>
>
> What you're describing is also the C subset of C++, so your experience
> applies just as well to C++!
>
>>
>> C++ removes some of this advantage -- now there is extra code generated by
>> the compiler to handle constructors, destructors, operators etc which can
>> make a material difference to fast inner loops. So you end up just writing
>> "C-style" anyway.
>
>
> This is in fact not true, and writing in C++ style can often produce faster
> code. A classic example of this is C qsort vs C++ std::sort. You may be
> thinking of using virtual functions in a class hierarchy, where a tradeoff
> between performance and run-time polymorphism is being done. Emulating the
> functionality that virtual functions provide in C will give similar
> performance characteristics as the C++ language feature itself.
>
>>
>> On the other hand, if your problem really is "write lots of OO code with
>> virtual methods and have it turned into machine code" (probably like the
>> GCC guys) then maybe C++ is the way to go.
>
>
> Managing the complexity of the dtype subsystem, the ufunc subsystem, the
> nditer component, and other parts of NumPy could benefit from C++ Not in a
> stereotypical "OO code with virtual methods" way, that is not how typical
> modern C++ is done.
>
>>
>> Some more opinions on C++:
>> http://gigamonkeys.wordpress.com/2009/10/16/coders-c-plus-plus/
>>
>> Sorry if this all seems a bit negative about C++. It's just been my
>> experience that C++ adds complexity while C keeps things nice and simple.
>
>
> Yes, there are lots of negative opinions about C++ out there, it's true.
> Just like there are negative opinions about C, Java, C#, and any other
> language which has become popular. My experience with regard to complexity
> and C vs C++ is that C forces the complexity of dealing with resource
> lifetimes out into all the code everyone writes, while C++ allows one to
> encapsulate that sort of complexity into a class which is small and more
> easily verifiable. This is about code quality, and the best quality C++ code
> I've worked with has been way easier to program in than the best quality C
> code I've worked with.

While I actually believe this to be true (very good C++ can be easier
to read/use than very good C). Good C is also much more common than
good C++, at least in open source.

On the good C++ codebases you have been working on, could you rely on
everybody being a very good C++ programmer ? Because this will most
likely never happen for numpy. This is the crux of the argument from
an organizational POV: the variance in C++ code quality is much more
difficult to control. I have seen C++ code that is certainly much
poorer and more complex than numpy, to a point where not much could be
done to save the codebase.

cheers,

David