c++ extension, problem passing argument

[Matteo]

On 14 Mar, 02:08, Aaron Brady <castiro... at gmail.com> wrote:
> On Mar 13, 5:42 pm, Matteo <tadweles... at gmail.com> wrote:
>
>
>
> > On 13 Mar, 22:35, Aaron Brady <castiro... at gmail.com> wrote:
>
> > > On Mar 13, 1:34 pm, Matteo <tadweles... at gmail.com> wrote:
>
> > > > hmmm... looks like SWIG has a problem with double pointers. I googled
> > > > around a bit and found:
>
> > > >http://osdir.com/ml/programming.swig/2003-02/msg00029.html
>
> > > > anyone knows how to write a small wrapper to do the appropriate
> > > > dereferencing?
>
> > > 'ctypes' may be able to do it.  I've done something like this in the
> > > past:
>
> > > double_ptr= ctypes._cast( PyObject, sing_ptr )
>
> > > Up your alley?
>
> > Thanks for your suggestions, but still no luck here.
>
> > ctypes appears to work only with its own types, I tried its cast,
> > byref and pointer functions, but only received TypeError exceptions
> > such as:
> > TypeError: byref() argument must be a ctypes instance, not 'list'
> > TypeError: _type_ must have storage info
>
> > This is getting really annoying :(
>
> > The following link may contain useful info, but I find it somewhat
> > obscurehttp://embedded.eecs.berkeley.edu/Alumni/pinhong/scriptEDA/pyTypemapF...
>
> I'm on my last one (suggestion).  To get a pointer to the actual
> address of an mmap instance, (and access it's 'data' attribute), I
> used the following:
>
> from _ctypes import _cast_addr
> from ctypes import *
> _mmap_cast= _data_cast= PYFUNCTYPE(py_object, py_object, py_object,
> py_object)(_cast_addr)
> _offset_cast= _record_cast = PYFUNCTYPE(py_object, c_void_p,
> py_object, py_object)(_cast_addr)
>
> class MMAP(Structure):
>     _fields_= [
>         #("next",c_int),
>         #("prev",c_int),
>         ("refcnt",c_int),
>         ("type",c_int),
>         ("data",c_long)
>         ]
>
> def pdata( map ):
>     a= _data_cast( map, None, POINTER( MMAP ) )
>     return a.contents.data
>
> It worked on my machine in 2.5, no promises.  It was a workaround for
> the '_type_ must have storage info' error.  Lo and behold,
> 'a.contents' was an MMAP, so '.data' was a 'c_long' interpretation of
> the 'char* data' member of the C structure, PyMmapObject or
> something.  I found it by studying the 'ctypes.cast' code.  Well good
> luck and sorry for the suggestions.

Umph... couldn't get this to work either. I'm starting a new thread,
reproducing the problem with the minimum amount of c++ and python
code, now that I know where the problem lies.

Again, thanks for your time.