On Sat, Feb 18, 2012 at 5:12 PM, Nathaniel Smith <n...@pobox.com> wrote:
> 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.
>
They are classes, data with methods in one cute little bundle.
> 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.
>
>
That's more like having destructors. Let the compiler do it, part of useful
code abstraction is to hide those sort of sordid details.
> 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.)
>
>
I think the low level library will ignore the Python memory allocator, but
there is a template for allocators that makes them selectable.
> Again, it really doesn't matter to me personally which approach is
> chosen. But getting more concrete might be useful...
>
>
Agreed. I think much will be clarified once there is some actual code to
look at.
Chuck
_______________________________________________
NumPy-Discussion mailing list
NumPy-Discussion@scipy.org
http://mail.scipy.org/mailman/listinfo/numpy-discussion
