On Sat, Feb 18, 2012 at 4:24 PM, David Cournapeau
<cournape@gmail.com> wrote:
On Sat, Feb 18, 2012 at 9:40 PM, Charles R Harris
<
charlesr.harris@gmail.com> wrote:
>
> Well, we already have code obfuscation (DOUBLE_your_pleasure,
> FLOAT_your_boat), so we might as well let the compiler handle it.
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 :)