Hi Kevin,
On Wed, 20 Jan 2016, Kevin Thornton wrote:
> The developers will have to weigh in, but I don't think that this is
> straightforward. Cython's C++ support appears to be trying to remain
> agnostic about C++98/11/14 at the moment.
Sure, but one can simply define a macro along the following lines:
#if __cplusplus > 199711L
#include <utility>
#define __Pyx_std_move(x) std::move(x)
#else
#define __Pyx_std_move(x) (x)
#endif
We can also use ">= 201103L" to stay on the safe side, but probably any
compiler that claims to support anything better than 199711L does have
support for move semantics (wild guess).
Maybe you are right though, and I should have sent this to the developer
list; not sure if this one is checked by Robert & Stefan and how often.
Also, I've noticed that there was some recent activity by Ian Henriksen
regarding exception handling for overloaded C++ operators. I'm not sure
what was the bottom line though, is it better to use the move hack, or
rather teach Cython that it shouldn't introduce temporaries for
non-copyiable objects? If that's the latter, then I'm out :-/ otherwise, I
could even try to come up with a pull request.
Orthogonally to that, some generators that I'm working with, like
CodeSynthesis XSD, for example, are getting options like `-std=c++14`, so
maybe that's yet another way to go, although, again, I don't know what the
core developers would favor.
> Have you tried simply creating a unique_ptr without make_unique? Would
> that be a sufficient workaround?
For now I've just left out the "except +" from my definition, the
downside, of course, is that if the exception is thrown from the type
constructor, the interpreter will crash.
> I'm not sure if it matters, but make_unique is defined as a variadic,
> and should take an rvalue reference instead of a non-const reference.
> Currently, Cython supports neither of those C++11 idioms.
Sure, I do know about that, but my declarations simply allow to make a
unique pointer out of a copy-constructable or default-constructable class,
which is all I currently need it for.
I've seen that Cython allows ellipsis (...) in function declarations, and
in theory I could have used that instead, but I couldn't find anything in
the documentation, so I thought I'd rather not do it.