Re: C++ Wrapper Confusion

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[0]  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.