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. > > 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. > > I found this<http://stackoverflow.com/questions/4978330/c-library-with-c-interface>, which references 0mq (used by ipython) as an example of a C++ library with a C interface. It seems enums can have different sizes in C/C++, so that is something to watch. Chuck
_______________________________________________ NumPy-Discussion mailing list NumPy-Discussion@scipy.org http://mail.scipy.org/mailman/listinfo/numpy-discussion