On Sun, Feb 19, 2012 at 2:14 AM, David Cournapeau <cournape <at> gmail.com
> On Sun, Feb 19, 2012 at 9:52 AM, Mark Wiebe <mwwiebe <at> gmail.com
>> On Sun, Feb 19, 2012 at 3:10 AM, Ben Walsh <ben_w_123 <at> yahoo.co.uk
>>> > 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++:
>>> 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.