Is this simple enough?
import numpy as np
cimport numpy as np
cdef extern from "gpumat.h" :
ctypedef struct dim3:
int x, y, z
ctypedef enum MatrixType :
Realmatrix = 0
Cuppermatrix = 2
ctypedef struct gpumat
void fromgpu(gpumat &gin, float *hval)
cdef cppclass gpumat:
The default constructor line gpumat() causes cython to complain.
By the way I left the numpy import directives in the .pyx file, but
they will generate a ton of errors when you actually start trying to
compile your .cpp file. (Just delete the last gpumat()) line to see
it. I seem to recall a statement in the documentation about C linkage
not really working for the C++ wrapper, although actually they are
compile time errors.
I think that deficiency may cause more problems than first thought, if
that's what's causing this error.
I suppose I should supply a .h file, but I can't give out my
proprietary gpumat.h, which is rather complex and it has a bunch of
dependencies on Nvidia's cuda drivers and libraries. I'll try to
create a minimal .h file and then add it to the bug tracker entry.
I guess I have a fundamental question about whether I will be able to
use the cython/numpy integration in my C++ wrapper. If not then I'll
have to go back to C linkage. As it is my C++ code is just a wrapper
for a bunch of C calls into some CUDA kernels. I do have a bunch of C+
+ code that uses my matrix class, but I suppose I can just create a C
wrapper for them if worst comes to worst.
What would be nice is if there was a SWIG, or maybe SIP translator
that translated C++ not directly to python, but rather to cython and
to a cython extension class to be used in python. It would solve some
of the speed deficiencies of the latter efforts and would permit
modifications/enhancements to the extension class at the cython level,
preserving some of the speed improvements.
In theory such a facility could use C linkage at the cython level,
though ultimately C++ integration will be superior. In my case it
would be desirable since my class probably has a hundred or more
methods and it will annoying wrapping them into a cdef'd class by
On Apr 7, 4:51 pm, Robert Bradshaw
> On Apr 7, 2010, at 1:19 PM, SevenThunders wrote:
> > OK well that makes sense then. I erroneously got the impression that
> > there was stealth support
> > for the new syntax.
> > I downloaded a development version and attempted to use it to start
> > wrapping a somewhat complex C++ class (that is fortunately no longer
> > templated). I pointed my PYTHONPATH to the install directory and the
> > linux PATH variable to the underlying bin directory. I ran into some
> > issues, some of which I could overcome, but the final issue is
> > baffling to me.
> > First I found that cython doesn't seem to handle type declarations of
> > the form std::string. Or at least whenever I used it as a type
> > signature in a function call it complained of a syntax error.
> You can't use C++ :: to denote namespaces, as :: has a completely
> meaning in Python. Instead, use
> cdef extern from "string" namespace std:
> cdef cppclass string
> (On that note, one thing that we don't yet provide is any nice Python
> <-> C++ string conversion.)
> > I then found that it doesn't like the ~ character in the destructor
> > declaration.
> Use del (which is they Python syntax). Again, the ~ operator already
> has a meaning in Python.
> FYI, Some good examples can be found athttp://hg.cython.org/cython-devel/file/tip/tests/run/cpp_templates.py...
> (and elsewhere in that directory). I think it's easier to take the
> perspective that you're writing Python that can call C++ than to try
> and think about writing C++ with Python syntax.
> > Next, when wrapping my extension class, it's single data attribute
> > is the pointer to the underlying C++ class. But how do you
> > dereference that pointer in cython code? After all a lot of my
> > methods take (const gpumat &) as the type signature. Well it seems
> > you have to drop the const declaration
> const support is a long-standing defect of Cython (though lower
> priority than some)
> > and then if you erroneously try
> > to pass *gptr as an argument, it treats it as a star argument within
> > python syntax, which I suppose is a kind of unbracket or list
> > extraction operator (reasonable I suppose).
> > So I think you have to do something like self.gptr as an argument.
> That's exactly right. You can also import the actual dereference
> operator (as a function) from cython.operator, see the above link.
> This is required in case the * and  have been overridden in
> incompatible ways.
> > I then found that cuda's dim3 struct type had to be declared
> > explicitly for some reason.
> Were you using it (or its members?)
> > Finally, after doing all this I ran cython on this code:
> Looks like you found a bug, I've made a ticket.http://trac.cython.org/cython_trac/ticket/523
> Can you boil this down to a smaller example?
> The new C++ support is a huge step forward, but there are still a lot
> of bugs to shake out, as it needs a lot of testing. Thanks so much for
> the feedback and hopefully we can get it working for you. There's
> always the "old way" of doing things, but that's both deprecated and
> - Robert
To unsubscribe, reply using "remove me" as the subject.