On Sun, Feb 19, 2012 at 3:10 AM, Ben Walsh <ben_w_123@yahoo.co.uk> wrote:
>>> > Date: Sun, 19 Feb 2012 01:18:20 -0600
> > From: Mark Wiebe <mwwiebe@gmail.com>
> > Subject: [Numpy-discussion] How a transition to C++ could work
> > To: Discussion of Numerical Python <NumPy-Discussion@scipy.org>
> > Message-ID:
> > <CAMRnEmpVTmt=
>KduRpZKtgUi516oQtqD4vAzm746HmpqgpFXNqQ@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.
Looking forward to seeing some more concrete examples.
>
In the interests of starting small, here's one that I mentioned in the
other thread:
Consider a regression like this:
http://mail.scipy.org/pipermail/numpy-discussion/2011-July/057831.html
Fixing this in C would require switching all the relevant usages of
NPY_MAXARGS to use a dynamic memory allocation. This brings with it the
potential of easily introducing a memory leak, and is a lot of work to do.
In C++, this functionality could be placed inside a class, where the
deterministic construction/destruction semantics eliminate the risk of
memory leaks and make the code easier to read at the same time.
Cheers,
Mark
> Cheers
>> Ben
> _______________________________________________
> NumPy-Discussion mailing list
>NumPy-Discussion@scipy.org>http://mail.scipy.org/mailman/listinfo/numpy-discussion>-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://mail.scipy.org/pipermail/numpy-discussion/attachments/20120219/7add1cb7/attachment-0001.html