On Fri, Feb 17, 2012 at 10:00 PM, David Cournapeau <courn...@gmail.com>wrote:
> > Le 18 févr. 2012 04:37, "Charles R Harris" <charlesr.har...@gmail.com> a > écrit : > > > > > > > > > On Fri, Feb 17, 2012 at 9:18 PM, David Cournapeau <courn...@gmail.com> > wrote: > >> > >> > >> Le 18 févr. 2012 03:53, "Charles R Harris" <charlesr.har...@gmail.com> > a écrit : > >> > >> > >> > > >> > > >> > > >> > On Fri, Feb 17, 2012 at 7:29 PM, David Cournapeau <courn...@gmail.com> > wrote: > >> >> > >> >> > >> >> Le 18 févr. 2012 00:58, "Charles R Harris" < > charlesr.har...@gmail.com> a écrit : > >> >> > >> >> > >> >> > > >> >> > > >> >> > > >> >> > On Fri, Feb 17, 2012 at 4:44 PM, David Cournapeau < > courn...@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
_______________________________________________ NumPy-Discussion mailing list NumPy-Discussion@scipy.org http://mail.scipy.org/mailman/listinfo/numpy-discussion
