[Numpy-discussion] Proposed Roadmap Overview

[Charles R Harris]

On Fri, Feb 17, 2012 at 10:00 PM, David Cournapeau <cournape at gmail.com>wrote:

>
> Le 18 févr. 2012 04:37, "Charles R Harris" <charlesr.harris at gmail.com> a
> écrit :
>
> >
> >
> >
> > On Fri, Feb 17, 2012 at 9:18 PM, David Cournapeau <cournape at gmail.com>
> wrote:
> >>
> >>
> >> Le 18 févr. 2012 03:53, "Charles R Harris" <charlesr.harris at gmail.com>
> a écrit :
> >>
> >>
> >> >
> >> >
> >> >
> >> > On Fri, Feb 17, 2012 at 7:29 PM, David Cournapeau <cournape at gmail.com>
> wrote:
> >> >>
> >> >>
> >> >> Le 18 févr. 2012 00:58, "Charles R Harris" <
> charlesr.harris at gmail.com> a écrit :
> >> >>
> >> >>
> >> >> >
> >> >> >
> >> >> >
> >> >> > On Fri, Feb 17, 2012 at 4:44 PM, David Cournapeau <
> cournape at 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
> missing?
>
> I believe that you cannot always guarantee that no exception will go
> through even with a catch all at the c++ -> c layer. I will try to find
> more about it, as I cannot remember the exact details I have in mind (need
> to look at the customer's code).
>

Stackoverflow<http://stackoverflow.com/questions/276102/catching-all-unhandled-c-exceptions>says
you can catch all MSVC MEH exceptions.

Chuck
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/numpy-discussion/attachments/20120217/ada88af6/attachment.html>