On Sat, Feb 18, 2012 at 4:24 PM, David Cournapeau <[email protected]>wrote:
> On Sat, Feb 18, 2012 at 9:40 PM, Charles R Harris > <[email protected]> wrote: > > > > > Well, we already have code obfuscation (DOUBLE_your_pleasure, > > FLOAT_your_boat), so we might as well let the compiler handle it. > > Yes, those are not great, but on the other hand, it is not that a > fundamental issue IMO. > > Iterators as we have it in NumPy is something that is clearly limited > by C. Writing the neighborhood iterator is the only case where I > really felt that C++ *could* be a significant improvement. I use > *could* because writing iterator in C++ is hard, and will be much > harder to read (I find both boost and STL - e.g. stlport -- iterators > to be close to write-only code). But there is the question on how you > can make C++-based iterators available in C. I would be interested in > a simple example of how this could be done, ignoring all the other > issues (portability, exception, etc…). > > The STL is also potentially compelling, but that's where we go into my > "beware of the dragons" area of C++. Portability loss, compilation > time increase and warts are significant there. > scipy.sparse.sparsetools has been a source of issues that was quite > high compared to its proportion of scipy amount code (we *do* have > some hard-won experience on C++-related issues). These standard library issues were definitely valid 10 years ago, but all the major C++ compilers have great C++98 support now. Is there a specific target platform/compiler combination you're thinking of where we can do tests on this? I don't believe the compile times are as bad as many people suspect, can you give some simple examples of things we might do in NumPy you expect to compile slower in C++ vs C? -Mark > > > > Jim Hugunin was a keynote speaker at one of the scipy conventions. At > dinner > > he said that if he was to do it again he would use managed code ;) I > don't > > propose we do that, but tools do advance. > > In an ideal world, we would have a better language than C++ that can > be spit out as C for portability. I have looked for a way to do this > for as long as I have been contributing to NumPy (I have looked at > ooc, D, coccinelle at various stages). I believe the best way is > actually in the vein of FFTW: written in a very high level language > (OCAML) for the hard part, and spitting out C. This is better than C++ > is many ways - this is also clearly not realistic :) > > David > _______________________________________________ > NumPy-Discussion mailing list > [email protected] > http://mail.scipy.org/mailman/listinfo/numpy-discussion >
_______________________________________________ NumPy-Discussion mailing list [email protected] http://mail.scipy.org/mailman/listinfo/numpy-discussion
