8 Apr 01:06 2010
Re: C++ Wrapper Confusion
SevenThunders <mattcbro <at> earthlink.net>
2010-04-07 23:06:19 GMT
2010-04-07 23:06:19 GMT
Is this simple enough? --------------badmat.pyx --------------- import numpy as np cimport numpy as np import sys cdef extern from "gpumat.h" : ctypedef struct dim3: int x, y, z ctypedef enum MatrixType : Realmatrix = 0 Complexmatrix=1 Cuppermatrix = 2 ctypedef struct gpumat void fromgpu(gpumat &gin, float *hval) cdef cppclass gpumat: int nrows int ncols int ld MatrixType mtype float *val dim3 block dim3 grid dim3 residual 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 hand. On Apr 7, 4:51 pm, Robert Bradshaw <rober... <at> math.washington.edu> wrote: > 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). > > Yep. > > > 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 > clumsy. > > - Robert -- -- To unsubscribe, reply using "remove me" as the subject.