SWIG

Andrea Fontana wrote:
> I can't force swig to choose my name/directory for generated
> headers... (swig 2.0.0)
> Here the line from my bash script:
> 
> swig -c++ -php -I$(dirname $0)/../swig/ -outdir $(dirname
> $0)/php/output/include -o $(dirname
> $0)/php/output/php_swig_interface.cpp -oh $(dirname
> $0)/php/output/php_swig_interface.hpp $(dirname
> $0)/../swig/CoreModule.i
> 
> It generates:
> /php/output/php_swig_interface.cpp
> /php/output/include/php_CoreModule.h
> /php/output/include/CoreModule.php
> 
> insteadof:
> 
> /php/output/php_swig_interface.cpp
> /php/output/php_swig_interface.hpp
> /php/output/include/CoreModule.php
> 
> what's wrong?

Works for me. Send a small tarball of the problem if you havn't fixed it 
including a full, but simpler bash script to recreate.

William

Kevin Chen wrote:
> Hi,
> 
> Section 31.4.2 of the SWIG documentation (at 
> http://www.swig.org/Doc2.0/Python.html#Python_nn30 ) discusses memory 
> management and shows an example of managing ownership in Python in cases 
> where one object is holding a reference to another object in C.
> 
> The section ends by mentioning that it's possible to deal with such 
> situations by using typemaps, but I wasn't able to find documentation 
> about this or figure it out -- how can I do so?
> 
> What I'm really trying to do is to take a newly created object 
> (instantiated from a constructor) and put it in an intrusive_ptr (since 
> most of the C libraries work with the object wrapped in an intrusive_ptr). 
> If I create the intrusive_ptr object in Python, then my original object 
> gets destructed shortly thereafter, leaving the intrusive_ptr with a stale 
> pointer.  I could set thisown on the original object to 0 manually, but it 
> would be nice if I could either:
> 
> 1. Wrap the constructor in SWIG such that the Python program never sees
>     the unwrapped object (preferable)
> 2. Set thisown to 0 automatically for all such objects created
>     (non-optimal, since could result in memory leaks)
> 
> Unfortunately, it seems that the "out" typemap doesn't apply to 
> constructors, so I was unable to get the first option to work.

You can use typemaps for constructor creation, eg:

%typemap(out) MyStruct * "/*out for MyStruct* */"
struct MyStruct {};

There is also the "ref" and "unref" feature for adding to constructors 
and destructors, see http://www.swig.org/Doc2.0/Python.html#Python_nn27a.

William

M.C.A. (Marco) Devillers wrote:
> Hi all,
> 
> I am writing a compiler, it can call C dynamic libraries through libdl
> and libffi. I want to use Swig to automate the binding process.
> 
> Since the compiler makes calls through ffi, it is unnecessary to
> generate C wrappers, a the moment. (With the exception of generating
> C++ wrappers, in which I am not interested at the moment.)
> 
> What I need from Swig is a manner to translate enums, constants, types
> and function prototypes to a binding in the target language.
> Preferably with a minimum of fuss, and preferably without changing
> header files at all.
> 
> I have a few questions regarding that, and thought it be best to put
> them directly in the list. For some of the answers I just need
> confirmation.
> 
> 1. Does Swig derive the types of constant definitions? (I.e., does it
> derive that in #define A 100, A is of type int?)
Yes.

> 2. Does Swig know the values of enum records? (I.e., in enum {X =100},
> does it know X has value 100)
This information is in the parse tree and only some target languages use it.

> 3. Is there a manner to easily convert a type definition to its C base
> type (a combination of char, int, long, float, double and pointer)?
> 4. The C generated C++ wrappers as generated by swig, does it perform
> this translation before it calls the language module?
Take a look at Typemaps and the run-time type checker in the 
documentation http://www.swig.org/Doc2.0/Typemaps.html

William

GoG wrote:
> Hi,
> I'd like to know if I can use '%apply' to define input, output and inout
> parameters of specific method
> without modifying my C++ headers (especially for Java).
> 
> Currently, in my interface file I have :
> %{#include MyClass.h %}
> 
> which include a class with this method :
> void MyClass::applyToPoint(double& x, double& y, double& z) const
> 
> Or :
> %apply double &INOUT { double &x, double &y, double &z };
> 
> is applied to every function with double &x, double &y, or double &z as
> parameters.
> 
> So, how can I specify the function to apply my parameters type to ?
> 
You can't. The only solution without modifying the headers is to copy 
the code from the header and put into your interface file and modify the 
parameter name in the interface file.

William

Graeme Smecher wrote:
>   Hi all,
> 
> A little more detail follows. SWIG's constructor handling for Lua seems 
> to be flawed.
> 
> On 10-07-18 01:33 PM, Graeme Smecher wrote:
>> I'm looking at the %extend keyword in a SWIG wrapper targeting both 
>> Lua and Python. There appears to be a bug in the code that emits 
>> constructors in Lua; it's not present in the same wrapper targeting 
>> Python.
>>
>> In Python:
>>
>>     >>> import vector_py
>>     >>> v = vector_py.Vector(1,2,3)
>>     >>> v.dump()
>>     Vector [1,2,3]
>>
>> In Lua:
>>
>>     > require("vector_lua")
>>     > v = vector_lua:Vector(1,2,3)
>>     Error in Vector expected 3..3 args, got 4
>>     stack traceback:
>>         [C]: in function 'Vector'
>>         stdin:1: in main chunk
>>         [C]: ?
>>
>> My guess is that SWIG's Lua support needs to be taught that 
>> constructors don't receive $self. This bug is present in SWIG versions 
>> 1.3.36 and 2.0.0; I'm using lua 5.1.4. The interface file follows:
>>
>>     #ifdef SWIGLUA
>>     %module vector_lua
>>     #endif
>>
>>     #ifdef SWIGPYTHON
>>     %module vector_py
>>     #endif
>>
>>     %{
>>             #include <math.h>
>>             typedef struct {
>>                     double x,y,z;
>>             } Vector;
>>     %}
>>
>>     typedef struct {
>>             double x,y,z;
>>     } Vector;
>>
>>     %extend Vector {
>>         Vector(double x, double y, double z) {
>>             Vector *v;
>>             v = (Vector *) malloc(sizeof(Vector));
>>             v->x = x;
>>             v->y = y;
>>             v->z = z;
>>             return v;
>>         }
>>         ~Vector() {
>>             free($self);
>>         }
>>         double magnitude() {
>>             return
>>     sqrt($self->x*$self->x+$self->y*$self->y+$self->z*$self->z);
>>         }
>>         void dump() {
>>             printf("Vector [%g, %g, %g]\n", $self->x,$self->y,$self->z);
>>         }
>>     };
>>
>>
>> I'll probably poke a little deeper, but I'm new to the SWIG codebase 
>> and I'm hoping a patch immediately suggests itself to a list member.
> 
> This is not just a problem with %extend; SWIG just doesn't emit valid 
> constructors for Lua. Here's a self-contained example:
> 
>     %module smallTest
> 
>     %{
>     #include <iostream>
> 
>     class A {
>         public:
>             A()    {std::cout<<"Hello world"<<std::endl;}
>     };
>     %}
> 
>     class A {
>         public:
>             A();
>     };
> 
> Compile as follows:
> 
>     $ swig -c++ -lua smallTest.i
>     $ g++ -shared -fPIC -o smallTest.so smallTest_wrap.cxx 
> -I/usr/include/lua5.1
> 
> Run as follows:
> 
>     Lua 5.1.4  Copyright (C) 1994-2008 Lua.org, PUC-Rio
>     > require("smallTest")
>     > a = smallTest:A()
>     Error in A expected 0..0 args, got 1
>     stack traceback:
>         [C]: in function 'A'
>         stdin:1: in main chunk
>         [C]: ?
>     >
> 
> The problem is clear from the .cxx wrapper:
> 
>     static int _wrap_new_A(lua_State* L) {
>       int SWIG_arg = 0;
>       A *result = 0 ;
> 
>       SWIG_check_num_args("A",0,0)
>       result = (A *)new A();
>       SWIG_NewPointerObj(L,result,SWIGTYPE_p_A,1); SWIG_arg++;
>       return SWIG_arg;
> 
>       if(0) SWIG_fail;
> 
>     fail:
>       lua_error(L);
>       return SWIG_arg;
>     }
> 
> 
> There are several errors here:
> 
>     * The constructor receives a "this" argument (it shouldn't);
>     * It checks to make sure it didn't receive "this", and complains (it 
> should); and finally,
>     * It then parses a "this" pointer (it shouldn't).
> 
> SWIG is a great tool, and I've used its Python modules with great 
> success. Any hints? With a little guidance, I'm willing to get the ball 
> rolling with a patch.
> 
The Lua code is in Source/Modules/lua.cxx and the typemaps in Lib/lua. 
There isn't a Lua maintainer at the moment, but I can look over any 
patch you provide

William

Camille Gillot wrote:
> Hello,
>
> I'm using SWIG Preprocessor for writing wrapper code, and I didn't 
> manage to
> get an unique identifier using __LINE__.
>
> I tried the following :
>
> > #define CAT_HELP(a,b) a##b
> > #define CAT(a,b) CAT_HELP(a,b)
> > #define UNIQUE_ID(a) CAT(a,__LINE__)
> > UNIQUE_ID(foo)
>
> And the only output I got was "foo__LINE__" (using both swig 1.3 and 
> 2.0),
> whereas gcc gives "foo4".
>
> Is there a known workaround ?
>
gcc 4.3 gives me a compile error with the above. Can you check your code 
and repost.

However, there is a problem with simple usage of __LINE__ with SWIG, 
which I am investigating.

William

I recently discovered how to use attribute.i and the %attribute
directive to create attributes with customized behavior, as in the
following (superfluous) example:

%attribute(Point, int, x, getX, setX);
%attribute(Point, int, y, getY, setY);
class Point {
public:
    int getX() { return _x };
    void setX(int x) { _x = x };
    int getY() { return _y };
    void setY(int y) { _y = y };
private:
   int _x;
   int _y;
}

It works great for my purposes, except for one thing: I can't figure
out how to make it work with template classes in a generic way. This
is what I've tried:

%attribute(Point<int>, int, x, getX, getY);  // Acheives the desired
effect, but only for Point<int> and not Point<double> etc.

%attribute(Point<T>, int, x, getX, getY); // Compiles, but doesn't
seem to have any useful effect on the generated module.

%attribute(Point<T>, T, x, getX, getY); // Doesn't compile -- says "T"
(in reference to the second T presumably) is not declared.

template<typename T>
%attribute(Point<T>, T, x, getX, getY); // Doesn't compile -- syntax
error for "template<..."

If possible, I would like to be able to create "template attributes,"
ie. attributes that get instantiations for every instantiation of the
owning class template. Otherwise, I will have to write an %attribute
line for every attribute of every instantiation of every class
instantiation that I want to use them.

I know it must show that I'm pretty new to SWIG. If the solution to
this problem seems obvious to anyone, please don't hesitate to point
it out to me anyway; I've been trying to figure out a way to achieve
this effect for a long time and any help would be much appreciated.

Thanks,
- Brad Harms

Hi all,
I'm trying to wrap a geometry module I wrote in C for use in Python,
and I want it to be able to use Python sequences of length 2 or 4.
After spending many hours looking at the Swig docs and examples on the
web, I came up with this code for my Swig interface:

%module geometry

%{
    // Converts a Python object into a C object of type T.
    // There must be a specialization of pyToC<T> in existence in order for the
    // conversion to be possible.
    // If the Python object could not be converted, an int exception is thrown.
    template<typename T> T pyToC(PyObject* o);

    //  Converts a Python sequence object to a new array of values of type T.
    //
    //  T:  The type of the objects in the array, and the type to which objects
    //      in the Python sequence must be convertible.
    //
    //  o:  The Python object to convert.
    //  a:  The array into which the results of the conversion will be stored.
    //  n:  Size of the array.
    //
    //  You can pass any Python object that fully implements the Python
    //  sequence protocol. However, all objects in the sequence must be of the
    //  same type, and that type must be one of the types for which there is an
    //  implementation of pyToC.
    //
    //  An exception of type int is raised when something goes wrong. If an
    //  exception is raised, no array is allocated and no cleanup is necessary.
    //  Exception codes:
    //  1:  Python object is not a sequence.
    //  2:  Could not determine the size of the sequence.
    //  3:  Size of the sequence does not match the given size 'n'.
    //  4:  Could not get one of the items from the sequence.
    //  5:  One of the objects in the sequence is not convertible to type T.
    //
    template <typename T>
    void
    pySequenceToCArray(PyObject *o, T a[], int n) {
        if (PySequence_Check(o)) {
            int size = PySequence_Length(o);
            if (size < 0) throw (2);
            if (size != n) throw (3);
            for (int i = 0; i < n; i++) {
                PyObject* item = PySequence_GetItem(o, i);
                if (!item) {
                    Py_XDECREF(item);
                    throw (4);
                }
                try {
                    a[i] = pyToC<T>(item);
                }
                catch (int) {
                    Py_XDECREF(item);
                    throw (5);
                }
                Py_DECREF(item);
            }
        }
        else {
            throw (1);
        }
    }

    template<> long pyToC<long>(PyObject* o) {
        long v = PyInt_AsLong(o);
        if (PyErr_Occurred()) throw (1);
        return v;
    }

    template<> int pyToC<int>(PyObject* o) {
        int v = (int)PyInt_AsLong(o);
        if (PyErr_Occurred()) throw (1);
        return v;
    }

    template<> double pyToC<double>(PyObject* o) {
        double v = PyFloat_AsDouble(o);
        if (PyErr_Occurred()) throw (1);
        return v;
    }

    template<> float pyToC<float>(PyObject* o) {
        float v = (float)PyFloat_AsDouble(o);
        if (PyErr_Occurred())  throw (1);
        return v;
    }
%}

%typemap(in) int [4] {
    static int xywh[4];
    try {
        pySequenceToCArray<int>($input, xywh, 4);
    }
    catch (int) {
        return NULL;
    }
    $1 = xywh;
}

This compiles fine, and the module imports OK. However, it seems Swig
isn't creating the correct mapping functions, because anywhere I try
to pass a python list to a SWIG-wrapped method, I get a
NotImplementError that lists the available overloads for the given
method, such as the following:

    import geometry
    r = geometry.IRect([1,2,3,4])
Traceback (most recent call last):
  File "<stdin>", line 1, in <module>
  File "geometry.py", line 185, in __init__
    this = _geometry.new_IRect(*args)
NotImplementedError: Wrong number of arguments for overloaded function
'new_IRect'.
  Possible C/C++ prototypes are:
    geometry::Rect< int >(int,int,int,int)
    geometry::Rect< int >(int const [2],int const [2])
    geometry::Rect< int >(geometry::Point< int > const
&,geometry::Point< int > const &)
    geometry::Rect< int >(int const [4])

In case it isn't obvious from the output above, IRect is a wrapper
around a C++ geometry::Rect<int> template instantiation, and the
constructor that I'm trying to call is geometry::Rect< int >(int const
[4]). However, it seems like my typemap isn't enough for SWIG to
understand that.

I've been at this for days. What am I doing wrong, or what am I missing?

Thanks in advance,
Brad

Dear all,

I am porting my Python module to Python 3. After some revisions to my
source code, the module compiles fine and can be imported in both
python 2.7 and python 3.1 (I am using swig 2.0). However, the Python 3
module does not work because returned objects (a reference) can not be
used due to missing "this" attribute. More specifically, suppose that
class Population has a list of Individuals. Function

Individual& Population::individual(int index)

returns a reference to one of the individuals. In Python 2.7

>>> pop = Population(100)
>>> ind = pop.individual(0)
>>> hasattr(ind, 'this')
True
>>> ind.sex()
1

However, in Python 3.1

>>> pop = Population(100)
>>> ind = pop.individual(0)
>>> hasattr(ind, 'this')
TypeError: in method 'Individual___setattr__', argument 1 of type
'simuPOP::Individual const *'
>>> dir(ind)
['__class__', '__cmp__', '__delattr__', '__dict__', '__doc__',
'__eq__', '__format__', '__ge__', '__getattr__', '__getattribute__',
'__gt__', '__hash__', '__init__', '__le__', '__lt__', '__module__',
'__ne__', '__new__', '__reduce__', '__reduce_ex__', '__repr__',
'__setattr__', '__sizeof__', '__str__', '__subclasshook__',
'__swig_destroy__', '__weakref__',  'setSex', 'sex', 'sexChrom',
'thisown']
>>> ind.sex()
Traceback (most recent call last):
  File "<stdin>", line 1, in <module>
TypeError: in method 'Individual_sex', argument 1 of type
'simuPOP::Individual const *'

Note that there is no 'this' attribute for the returned Individual object.

I traced into the generated code and find that the TypeError is
generated due to failed call to function SWIG_Python_GetSwigThis in
function SWIG_Python_ConvertPtrAndOwn so the missing 'this' attribute
is likely causing the problem. I can provide more details or a
complete test case if more information is needed.

Thank you very much,
Bo

I've written a class in C++ that I've wrapped in Swig and called from Perl.
Everything seems to work, except I'm noticing some potential memory
weirdness.   The C++ class does some new[]'s inside upon construction.

How do the Perl garbage collector and the C++ malloc()/new() libs coexist?
If malloc() reserves a block of memory, how does Perl know not to reserve
from the same block?   I'm also assuming that when a Perl object goes
completely out of scope with 0 references on the Perl side of things, that
it will call the destructor for the object.  Take the following example in
Perl:

{
my $x = Test::new_cObj();  # using SWIG to create a new object
my $y = Test::new_cObjContainer();
$y->addObj( $x );   # adds $x to the $y object
}

# ??? is the $x object deleted by Perl at this point?

I'm assuming yes, because Perl has no way of knowing that $y holds a
reference to $x.    And holding a boost::shared_ptr in $y probably wouldn't
help:  Perl would still call delete on $x, correct?

Thanks,

Isaac

Hello William,

Sylvestre Ledru wrote:
> > Hello,
> > 
> > Sorry for the silly question but I would like to map the following
> > function:
> > int putDoubleComplex(char * variableName, double variableReal[],
double
> > variableImg[], int nbRow, int nbCol);
> > into Java.
> > 
> > I would like this function available in Java as 
> > int putDoubleComplex(String variableName, double[][] variableReal,
> > double[][] variableImg);
> > 
> > 
> > I have been able to manage some problems (SWIGTYPE removed) thanks
to
> > the following lines:
> > 
> > // SWIGTYPE_p_double.getCPtr => variableReal
> > %typemap(javain) double[ANY], double[] "$javainput"
> > 
> > //%typemap(jni) double[] "jobjectArray"
> > %typemap(jtype) double[] "double[][]"
> > %typemap(jstype) double[] "double[][]"
> > 
> > However, I am struggling to tell to Swig that it should transform 
> > char * variableName, double variableReal[], double variableImg[],
int
> > nbRow, int nbCol
> > into
> > String variableName, double[][] variableReal, double[][] variableImg
> 
> 
> If the array was followed by the two array dimensions you'd be able 
> to use multi-argument typemaps to collapse the three parameters into
> one. This would work for example if you had instead:
> 
> int putDoubleComplex(char * variableName, double variableReal[], int 
> nbRow, int nbCol);
> to become
> int putDoubleComplex(char * variableName, double[][] variableReal);
Well, it is what I am doing for non complex values. ;)


> but your function declaration doesn't conform to having successive 
> parameters that you can collapse into one parameter and so the only 
> approach I can think of is to write a more SWIG friendly C method
> that calls into putDoubleComplex.
OK. I was hoping for a "better" solution. However, thanks for your
answer.

Sylvestre

Hi everybody,
I'm trying to figure out how to tell Swig to use different jni.h (and
jni_md.h) header
to generate my Java-C++ wrappers. I tried to use :
swig -java -I my/jni.h/include/dir [...]

Or to set env var :
JAVA_INCLUDE=my/jni.h/include/dir

But it seems to still use is own header (Sun one here).
I think it was set during the configure script run
(I'm working on Linux).

So, is there a way to change/set jni.h header used by Swig ?

Thanks.
-- 
View this message in context: http://old.nabble.com/-Java--Specifiy-different-jni.h-header-tp29531949p29531949.html
Sent from the swig-user mailing list archive at Nabble.com.

CoSMo Software is currently looking for collaborators to join the
team. We are seeking talented individuals right now!

About CoSMo

The CoSMo Company design and develop leading edge, high quality
software in the fields of complex systems. Our solutions can be
applied to systems biology modeling, environment as well as simulation
of dynamic systems (social networks, economy...). The CoSMo Company's
business model is tailored after an open source one to provide
low-cost technical solution, reusable technology and long term
maintenance. Our mission is to provide our clients with tools to
integrate knowledge within models, and to use those models within
simulation for prediction. The capacity to understand complex
phenomena through simulation will improve productivity, increase
success rate and reduce time to market.

The job

Your job will focus on developing open-source product in the
bio-medical image processing field. The location will be Boston.
However for exceptional American candidates, working remotely could be
possible. We may also accept recently graduate French engineers
willing to relocate to Boston. Positions are one-year, full-time, which
can evolve into longer term contracts. Technical reviews may be part
of the recruitment process.

Candidates will be working on enhancing WrapITK, the wrapping system
based on SWIG used by the Insight Toolkit (ITK). ITK is heavily
templated and supported on a lot of platforms, making it challenging
to wrap. Several new languages will be supported, including C# and
Python 3. All the developments will be open-source and freely
available under a BSD license.

By joining our team you will participate in a dynamic work
environment, with exceptionally talented co-workers, and collaborate
with esteemed researchers from around the world by:

  * designing and developing new software in ITK.
  * implementing, documenting, analyzing, creating and modifying
computer systems or programs.

Candidates for this position must posses the following basic skills:

  * ability to develop software for Unix, MacOSX and/or Windows OSes
  * experience with SWIG mandatory
  * knowledge of *either* Java, C# or python 3 a must
  * experience of writing CMake scripts
  * experience with WrapITK a big plus
  * knowledge of ITK, VTK or Paraview a plus;

-- 
Gaëtan Lehmann
Biologie du Développement et de la Reproduction
INRA de Jouy-en-Josas (France)
tel: +33 1 34 65 29 66    fax: 01 34 65 29 09
http://voxel.jouy.inra.fr  http://www.itk.org
http://www.mandriva.org  http://www.bepo.fr

Hi,

I try to use a director in my project in order to define a callback class.
The compilation of the generated code works fine - linking fails however
with the error message 

undefined reference to `_imp___ZTV26MDCS_GetDBResultsCCallback' 

see below (MDCS_GetDBResultsCCallback is the name of the callback class).

When I remove

%feature("director") MDCS_GetDBResultsCCallback;

from my .i file both steps work fine.

Do I have to add any additional libraries to the command line for the
linking command? (I am using the g++ compiler from MinGW)

Thanks and regards

Bernd


 g++ -Wall -c MDCStoreUtilsApi_wrap.cxx -I../../../api/SDK/API
-I../../../MinGW/include -I../includes/jre -I../includes/jre/win32
 g++ -Xlinker --enable-auto-import -shared -Wall -o MDCStoreUtils_wrap.dll
MDCStoreUtilsApi_wrap.o -L../../../api/SDK/API -lMDCStoreUtils 

MDCStoreUtilsApi_wrap.o:MDCStoreUtilsApi_wrap.cxx:(.text$_ZN26MDCS_GetDBResultsCCallbackC2Ev[MDCS_GetDBResultsCCallback::MDCS_GetDBResultsCCallback()]+0x4):
undefined reference to `_imp___ZTV26MDCS_GetDBResultsCCallback'

MDCStoreUtilsApi_wrap.o:MDCStoreUtilsApi_wrap.cxx:(.text$_ZN26MDCS_GetDBResultsCCallbackD2Ev[MDCS_GetDBResultsCCallback::~MDCS_GetDBResultsCCallback()]+0x7):
undefined reference to `_imp___ZTV26MDCS_GetDBResultsCCallback'

MDCStoreUtilsApi_wrap.o:MDCStoreUtilsApi_wrap.cxx:(.text$_ZN26MDCS_GetDBResultsCCallbackD1Ev[MDCS_GetDBResultsCCallback::~MDCS_GetDBResultsCCallback()]+0x7):
undefined reference to `_imp___ZTV26MDCS_GetDBResultsCCallback'
 collect2: ld returned 1 exit status
 mingw32-make: *** [all] Error 1
-- 
View this message in context: http://old.nabble.com/Linking-fails-when-using-directors-tp29519451p29519451.html
Sent from the swig-user mailing list archive at Nabble.com.

On 8/20/10 1:15 PM, "Asher Langton" <langton2@...> wrote:
> On 8/20/10 11:10 AM, "William S Fulton" <wsf@...> wrote:
>> Given you haven't provided the full information and I'm too lazy to
>> guess it, please send a complete cutdown minimal working version of your
>> definitions of B,C and D and I'll take a look.
> 
> I've attached code that defines B, C, and D in a way that reproduces the
> error I've been seeing.  Here's the output:
> ...

The error disappears if I add an extra template directive to C.i:

%module C_mod
namespace boost {
    template <class T>
    class shared_ptr{
        T * operator->() const;
    };
};

%{
#include "C.hh"
%}

%import "B.hh"
%import "D.hh"
%include "C.hh"

%template (C_int) C<int>;
%template (C_int_Btype) boost::shared_ptr<D <C<int>::BType > >;


I'll check whether this solves the problem for the real code from which this
example was derived.

-Asher

Hello,

I need to define qint32 to use this class


class AbstractIdLongMutable {

private :
  //***************************************************************************
  //* Propriétés
  //***************************************************************************

  qint32 valeur;

public :
  //***************************************************************************
  //* Méthodes publiques
  //***************************************************************************

  // Destructeur
  virtual ~AbstractIdLongMutable() {}

  // Accesseurs
  qint32 getValeur() const;
  void setValeur(qint32 pValeur);

protected :
  //***************************************************************************
  //* Méthodes protégées
  //***************************************************************************

  // Affectation
  AbstractIdLongMutable& operator=(const AbstractIdLongMutable& pRhv);

  // Comparateurs
  bool operator==(const AbstractIdLongMutable& pRhv) const;
  bool operator!=(const AbstractIdLongMutable& pRhv) const;
  bool operator<(const AbstractIdLongMutable& pRhv) const;

  // Constructeurs
  AbstractIdLongMutable();
  AbstractIdLongMutable(qint32 pValeur);
  AbstractIdLongMutable(const AbstractIdLongMutable& pCopie);

private :
  //***************************************************************************
  //* Méthodes privées
  //***************************************************************************

};

I defined in file.i like this : 
#typedef int qint32
%typemap(jni) qint32 "jint"
%typemap(jtype) qint32 "int"
%typemap(jstype) qint32 "int"


But the generated code give this :
  public int getValeur() {
    return new SWIGTYPE_p_qint32(MiddlewareJNI.AbstractIdLongMutable_getValeur(swigCPtr, this), true);
  }


I don't want SWIGTYPE_p_qint32. Can i do to return int directly.

Thanks for help
Vincent

Sylvestre Ledru wrote:
> Hello,
> 
> Sorry for the silly question but I would like to map the following
> function:
> int putDoubleComplex(char * variableName, double variableReal[], double
> variableImg[], int nbRow, int nbCol);
> into Java.
> 
> I would like this function available in Java as 
> int putDoubleComplex(String variableName, double[][] variableReal,
> double[][] variableImg);
> 
> 
> I have been able to manage some problems (SWIGTYPE removed) thanks to
> the following lines:
> 
> // SWIGTYPE_p_double.getCPtr => variableReal
> %typemap(javain) double[ANY], double[] "$javainput"
> 
> //%typemap(jni) double[] "jobjectArray"
> %typemap(jtype) double[] "double[][]"
> %typemap(jstype) double[] "double[][]"
> 
> However, I am struggling to tell to Swig that it should transform 
> char * variableName, double variableReal[], double variableImg[], int
> nbRow, int nbCol
> into
> String variableName, double[][] variableReal, double[][] variableImg
> 

If the array was followed by the two array dimensions you'd be able to 
use multi-argument typemaps to collapse the three parameters into one. 
This would work for example if you had instead:

int putDoubleComplex(char * variableName, double variableReal[], int 
nbRow, int nbCol);

to become

int putDoubleComplex(char * variableName, double[][] variableReal);

but your function declaration doesn't conform to having successive 
parameters that you can collapse into one parameter and so the only 
approach I can think of is to write a more SWIG friendly C method that 
calls into putDoubleComplex.

William

Dmitriy Matveev wrote:
> Hello!
> Consider following test case:
> struct S1
> {
> 	int kind;
> 	union {
> 		int i; // kind == 0
> 		struct {
> 			int j, k;
> 		} s; // kind == 1
> 	} variant;
> };
> 
> By default SWIG will generate such wrappers that access to union
> fields can be made in following way:
> s1.getVariant().getI() or s1.getVariant().getS()
> I want to access them in shorter form, without getVariant() call and
> also I want to apply contracts to make it safer.
> 
> My first try was extension of S1 by new methods:
> 
> %ignore S1::variant;
> 
> %contract S1::getI {
> 	require:
> 		$self->kind == 0
> }
> 
> %extend S1 {
> 	int getI()
> 	{
> 		return $self->variant.i;
> 	}
> }
> 
> %contract S1::getS {
> 	require:
> 		$self->kind == 1
> }
> 
> %extend S1 {
> 	S1_variant_s *getS()
> 	{
> 		return &$self->variant.s;
> 	}
> };
> 
> Almost everything was OK, but code for S1_getS function wasn't
> compilable since definition of S1_variant_s function was put after it
> (not before):
> 
> SWIGINTERN S1_variant_s *S1_getS(struct S1 *self){
>                 return &self->variant.s;
>         }
> typedef union {
>   int i;
>   struct {
>     int j, k;
>   } s;
> } S1_variant;
> 
> My next try was definition of fake fields and getters for them:
> %ignore S1::variant;
> 
> %contract S1::getI {
> 	require:
> 		$self->kind == 0
> }
> 
> %extend S1 {
> 	int i;
> 	S1_variant_s s;
> }
> 
> %contract S1::getS {
> 	require:
> 		$self->kind == 1
> }
> 
> %wrapper %{
> 	int S1_i_get(struct S1 *self)
> 	{
> 		return self->variant.i;
> 	}
> 
> 	S1_variant_s *S1_s_get(struct S1 *self)
> 	{
> 		return (S1_variant_s*)&self->variant.s;
> 	}
> %}
> 
> The code was compileable, but contracts wasn't applied. I also tried
> things like:
> %contract S1::s {
> 	require:
> 		$self->kind == 1
> }
> 
> %contract S1::s_get {
> 	require:
> 		$self->kind == 1
> }
> 
> Is it possible to add a contract for field getter somehow? If not,
> maybe I can workaround this somehow? Thanks.
> 

Contracts only work on functions. Changes to SWIG in 
Source/Modules/contract.cxx would be required to add contracts to 
variables. I'm not sure how you would distinguish contract code for the 
get and set variable though. You could try put some assertion code in 
the 'check' typemap instead for variables.

Mostly I think you are trying to customize nested structs (which is only 
weakly supported) just too far.

William