SWIG Typemap for Two-way Conversion Between Python Stringand

Hi,

I’ve read that we can specify a typemap to change an input Python string
to
(char*,int) in C++.

How do we specify a typemap for a C++ extension that also converts such
strings from C++ to Python? I want to have C++ calls that receive
strings
from Python code as well as C++ calls that pass strings to Python code.

Thanks,
Jeremy

On Fri, 2007-01-05 at 21:48 +0800, Jeremy Chew wrote:

How do we specify a typemap for a C++ extension that also converts such
strings from C++ to Python? I want to have C++ calls that receive strings
from Python code as well as C++ calls that pass strings to Python code.

The good news is that the standard SWIG library has already done most of
the work for you. If you add:

%include std_string.i

…in your .i file, then SWIG automagically (using typemaps) converts
between the STL std::string type and Python strings.

More documentation is here:

http://www.swig.org/Doc1.3/Library.html

…where you’ll see similar examples for converting between std::vector
and Python lists, std::map and Python dictionaries, and more.


Johnathan C., AE6HO
Corgan Enterprises LLC
[email protected]

Thanks.

I’ve been getting problems compiling the resultant *_wrap.c file after
adding %include"std_string.i".
gcc version 3.4.3 says it can’t find .

Explicitly including the directory -I/usr/include/c++/3.4.3 in the gcc
command doesn’t work.
Neither does changing the *_wrap.c filename to *_wrap.cpp.
With *_wrap.c, gcc doesn’t seem to compile the C++ code that comes with
.
With *_wrap.cpp, gcc fails as SWIG seems to wrap the std namespace,
using
‘std’ and ‘namespace’ as variables rather than as keywords or scope
names.

How do we work through this?

----- Original Message -----
From: “Johnathan C.” [email protected]
To: “Jeremy Chew” [email protected]
Cc: [email protected]
Sent: Saturday, January 06, 2007 12:29 AM
Subject: Re: [Discuss-gnuradio] SWIG Typemap for Two-way Conversion
BetweenPython Stringand (char*, int) in C++

This forum is not affiliated to the Ruby language, Ruby on Rails framework, nor any Ruby applications discussed here.

| Privacy Policy | Terms of Service | Remote Ruby Jobs