On Sat, Feb 18, 2012 at 10:54 PM, Travis Oliphant <tra...@continuum.io> wrote:
> I'm reading very carefully any arguments against using C++ because I've
> actually pushed back on Mark pretty hard as we've discussed these things over
> the past months. I am nervous about corner use-cases that will be unpleasant
> for some groups and some platforms. But, that vague nervousness is not
> enough to discount the clear benefits. I'm curious about the state of C++
> compilers for Blue-Gene and other big-iron machines as well. My impression
> is that most of them use g++. which has pretty good support for C++.
> David and others raised some important concerns (merging multiple compilers
> seems like the biggest issue --- it already is...). If someone out there
> seriously opposes judicious and careful use of C++ and can show a clear
> reason why it would be harmful --- feel free to speak up at any time. We
> are leaning that way with Mark out in front of us leading the charge.
I don't oppose it, but I admit I'm not really clear on what the
supposed advantages would be. Everyone seems to agree that
-- Only a carefully-chosen subset of C++ features should be used
-- But this subset would be pretty useful
I wonder if anyone is actually thinking of the same subset :-).
Chuck mentioned iterators as one advantage. I don't understand, since
iterators aren't even a C++ feature, they're just objects with "next"
and "dereference" operators. The only difference between these is
spelling:
for (my_iter i = foo.begin(); i != foo.end(); ++i) { ... }
for (my_iter i = my_iter_begin(foo); !my_iter_ended(&i);
my_iter_next(&i)) { ... }
So I assume he's thinking about something more, but the discussion has
been too high-level for me to figure out what.
Using C++ templates to generate ufunc loops is an obvious application,
but again, in the simple examples I'm thinking of (e.g., the stuff in
numpy/core/src/umath/loops.c.src), this pretty much comes down to
whether we want to spell the function names like "SHORT_add" or
"add<short>", and write the code like "*(T *))x[0] + ((T *)y)[0]" or
"((@TYPE@ *)x)[0] + ((@TYPE@ *)y)[0]". Maybe there are other places
where we'd get some advantage from the compiler knowing what was going
on, like if we're doing type-based dispatch to overloaded functions,
but I don't know if that'd be useful for the templates we actually
use.
RAII is pretty awesome, and RAII smart-pointers might help a lot with
getting reference-counting right. OTOH, you really only need RAII if
you're using exceptions; otherwise, the goto-failure pattern usually
works pretty well, esp. if used systematically.
Do we know that the Python memory allocator plays well with the C++
allocation interfaces on all relevant systems? (Potentially you have
to know for every pointer whether it was allocated by new, new[],
malloc, or PyMem_Malloc, because they all have different deallocation
functions. This is already an issue for malloc versus PyMem_Malloc,
but C++ makes it worse.)
Again, it really doesn't matter to me personally which approach is
chosen. But getting more concrete might be useful...
-- Nathaniel
_______________________________________________
NumPy-Discussion mailing list
NumPy-Discussion@scipy.org
http://mail.scipy.org/mailman/listinfo/numpy-discussion
