[Numpy-discussion] Proposed Roadmap Overview

Charles R Harris charlesr.harris@gmail....
Fri Feb 17 22:37:24 CST 2012

On Fri, Feb 17, 2012 at 9:18 PM, David Cournapeau <cournape@gmail.com>wrote:

> Le 18 févr. 2012 03:53, "Charles R Harris" <charlesr.harris@gmail.com> a
> écrit :
> >
> >
> >
> > On Fri, Feb 17, 2012 at 7:29 PM, David Cournapeau <cournape@gmail.com>
> wrote:
> >>
> >>
> >> Le 18 févr. 2012 00:58, "Charles R Harris" <charlesr.harris@gmail.com>
> a écrit :
> >>
> >>
> >> >
> >> >
> >> >
> >> > On Fri, Feb 17, 2012 at 4:44 PM, David Cournapeau <cournape@gmail.com>
> wrote:
> >> >>
> >> >> I don't think c++ has any significant advantage over c for high
> performance libraries. I am not convinced by the number of people argument
> either: it is not my experience that c++ is easier to maintain in a open
> source context, where the level of people is far from consistent. I doubt
> many people did not contribute to numoy because it is in c instead if c++.
> While this is somehow subjective, there are reasons that c is much more
> common than c++ in that context.
> >> >
> >> >
> >> > I think C++ offers much better tools than C for the sort of things in
> Numpy. The compiler will take care of lots of things that now have to be
> hand crafted and I wouldn't be surprised to see the code size shrink by a
> significant factor.
> >>
> >> There are two arguments here: that c code in numpy could be improved,
> and that c++ is the best way to do it. Nobody so far has argued against the
> first argument. i think there is a lot of space to improve things while
> still be in C.
> >>
> >> You say that the compiler would take care of a lot of things: so far,
> the main thing that has been mentionned is raii. While it is certainly a
> useful concept, I find it ewtremely difficult to use correctly in real
> applications. Things that are simple to do on simple examples become really
> hard to deal with when features start to interact with each other (which is
> always in c++). Writing robust code that is exception safe with the stl
> requires a lot of knowledge. I don't have this knowledge. I have .o doubt
> Mark has this knowledge. Does anyone else on this list has ?
> >
> >
> > I have the sense you have written much in C++. Exception handling is
> maybe one of the weakest aspects of C, that is, it basically doesn't have
> any. The point is, I'd rather not *have* to worry much about the C/C++ side
> of things, and I think once a solid foundation is in place I won't have to
> nearly as much.
> >
> > Back in the late 80's I used rather nice Fortran and C++ compilers for
> writing code to run in extended DOS (the dos limit was 640 KB at that
> time). They were written in - wait for it - Pascal. The authors explained
> this seemingly odd decision by claiming that Pascal was better for bigger
> projects than C, and I agreed with them ;) Now you can point to Linux,
> which is 30 million + lines of C, but that is rather exceptional and the
> barriers to entry at this point are pretty darn high. My own experience is
> that beginners can seldom write more than a page of C and get it right,
> mostly because of pointers. Now C++ has a ton of subtleties and one needs
> to decide up front what parts to use and what not, but once a well designed
> system is in place, many things become easier because a lot of housekeeping
> is done for you.
> >
> > My own concern here is that the project is bigger than Mark thinks and
> he might get sucked off into a sideline, but I'd sure like to see the
> experiment made.
> >>
> >> >> I would much rather move most part to cython to solve subtle ref
> counting issues, typically.
> >> >
> >> >
> >> > Not me, I'd rather write most stuff in C/C++ than Cython, C is
> cleaner ;) Cython good for the Python interface, but once past that barrier
> C is easier, and C++ has lots of useful things.
> >> >>
> >> >> The only way that i know of to have a stable and usable abi is to
> wrap the c++ code in c. Wrapping c++ libraries in python  has always been a
> pain in my experience. How are template or exceptions handled across
> languages ? it will also be a significant issue on windows with open source
> compilers.
> >> >>
> >> >> Interestingly, the api from clang exported to other languages is in
> c...
> >> >
> >> >
> >> > The api isn't the same as the implementation language. I wouldn't
> prejudge these issues, but some indication of how they would be solved
> might be helpful.
> >>
> >> I understand that api and inplementation language are not the same: you
> just quoted the part where I was mentioning it :)
> >>
> >> Assuming a c++ inplementation with a c api, how will you deal with
> templates ? how will you deal with exception ? How will you deal with
> exception crossing dll/so between different compilers, which is a very
> common situation in our community ?
> >
> >
> > None of these strike me as relevant, I mean, they are internals, not api
> problems, and shouldn't be visible to the user. How Mark would implement
> the C++ API, as opposed to the C API I don't know, but since both would be
> there I don't see the problem. But really, we need more details on how
> these things would work.
> I don't understand why you think this is not relevant ? If numpy is in
> c++, with a C API, most users of numpy C/C++ API will use the C API, at
> least at first, since most of them are in C. Changes of restrictions on how
> this API xan be used is visible.
> To be more concrete, if numpy is built by MS compiler, and an exception is
> thrown, you will have a lots of trouble with an extension built with gcc.

Why would you even see an exception if it is caught before it escapes? I
would expect the C API to behave just as it currently does. What am I

> I have also observed some weird things in linux when mixing intel and gcc.
> This will have significant impacts on how people will be able to use
> extensions.
> I am a bit surprised by the claim.that abi and cross language API are not
> an issue with c++: it is a widely shared issue even within c++ proponents.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://mail.scipy.org/pipermail/numpy-discussion/attachments/20120217/6814fc9f/attachment.html 

More information about the NumPy-Discussion mailing list