SWIG

Hi.  I have a C++ function that looks like this:

  int read(void *buffer, size_t len);

This function will store len bytes into buffer.  I want to use this
function from Python, something like this:

  >>> b = bytearray('\0' * 100)
  >>> myCPPObject.read(b, 24, 8)

This would read 8 bytes into b starting at offset 24.  I want the
wrapper function to check that the 24+8 isn’t outside the bounds of the
the bytearray, too.  Is this possible to do with typemaps?  I can see
that I can use PyObject_AsWriteBuffer to convert my bytearray PyObject
into a pointer that I can pass into read(), but I don’t know how to say
that those two C++ function arguments get mapped to three Python
arguments.

If this is not possible, how can I write a custom wrapper function?  I
had a look through the documentation, but couldn’t see anything about
writing whole custom wrapper functions.  I am using SWIG 1.3.31.

Thanks,

Cameron

-- 
Cameron McCormack ≝ http://mcc.id.au/

If you create the following simple example.i for octave;

%module example
#define SPECIAL_VALUE 42

Then wrap and build it

swig -octave -c++ -o example.cpp example.i
mkoctfile example.cpp

The variable is available at the octave command-line level, but is undefined
within octave functions.

octave:1> example
octave:2> SPECIAL_VALUE
SPECIAL_VALUE =  42
octave:3> function test()
> SPECIAL_VALUE
> endfunction
octave:4> test
error: SPECIAL_VALUE' undefined near line 2 column 1
error: called from:
error:   test at line 2, column 1

These "undefined" results for accessing #define'd values from Octave
functions were obtained with Octave version 3.2.4 and swig version
1.3.40-3 from Debian testing.  I also tried putting "global
SPECIAL_VALUE" in the function, but that did not change the result.

I looked at the swig-generated example.cc code, and did notice
this anomalous piece of code.

bool global_option=true; // * swig cli option should control this default
for (int j=0;j<args.length();++j)
   if (args(j).is_string()&&args(j).string_value()=="noglobal")
     global_option=true;
   else if (args(j).is_string()&&args(j).string_value()=="noglobal")
     global_option=false;

That logic only makes sense to me if the first "noglobal" is replaced
by "global".  Otherwise, the second stanza is never executed. But I
think that is a different bug since the net result is no matter what
the user specifies on the swig command line, the result will always be
global_option=true.

Wrapping C #defines from python, java, and lua make those values
globally accessible so I don't understand what is wrong in the octave
case. (The PLplot developers wrap the PLplot API for those first three
languages using swig, and I am now working on doing the same thing for
octave).

I don't know whether this undefined octave result in functions is due
to some misunderstanding on my part, some swig octave module bug, some
incompatibility between the swig and octave versions, or some octave
bug so I thought the issue should be discussed here before possibly
reporting it to either the swig or octave bug trackers.

Alan
__________________________
Alan W. Irwin

Astronomical research affiliation with Department of Physics and Astronomy,
University of Victoria (astrowww.phys.uvic.ca).

Programming affiliations with the FreeEOS equation-of-state implementation
for stellar interiors (freeeos.sf.net); PLplot scientific plotting software
package (plplot.org); the libLASi project (unifont.org/lasi); the Loads of
Linux Links project (loll.sf.net); and the Linux Brochure Project
(lbproject.sf.net).
__________________________

Linux-powered Science
__________________________