5 SWIG and C++

• Comments on C++ Wrapping
• Approach
• Supported C++ features
• Command line options and compilation
• Simple C++ wrapping
  • Constructors and destructors
  • Default constructors
  • When constructor wrappers aren't created
  • Copy constructors
  • Member functions
  • Static members
  • Member functions and default arguments
  • Member data
• Protection
• Enums and constants
• Friends
• References and pointers
• Pass and return by value
• Inheritance
• A brief discussion of multiple inheritance, pointers, and type checking
• Renaming
• Wrapping Overloaded Functions and Methods
  • Dispatch function generation
  • Ambiguity in Overloading
  • Ambiguity resolution and renaming
  • Comments on overloading
• Wrapping overloaded operators
• Class extension
• Templates
• Namespaces
• Exception specifiers
• Pointers to Members
• Smart pointers and operator->()
• Using declarations and inheritance
• Partial class definitions
• A brief rant about const-correctness
• Proxy classes
  • Construction of proxy classes
  • Resource management in proxies
  • Language specific details
• Where to go for more information

5.1 Comments on C++ Wrapping

In part, the problem with C++ wrapping is that there is no semantically obvious (or automatic ) way to map many of its advanced features into other languages. As a simple example, consider the problem of wrapping C++ multiple inheritance to a target language with no such support. Similarly, the use of overloaded operators and overloaded functions can be problematic when no such capability exists in a target language.

A more subtle issue with C++ has to do with the way that some C++ programmers think about programming libraries. In the world of SWIG, you are really trying to create binary-level software components for use in other languages. In order for this to work, a "component" has to contain real executable instructions and there has to be some kind of binary linking mechanism for accessing its functionality. In contrast, C++ has increasingly relied upon generic programming and templates for much of its functionality. Although templates are a powerful feature, they are largely orthogonal to the whole notion of binary components and libraries. For example, an STL vector does not define any kind of binary object for which SWIG can just create a wrapper. To further complicate matters, these libraries often utilize a lot of behind the scenes magic in which the semantics of seemingly basic operations (e.g., pointer dereferencing, procedure call, etc.) can be changed in dramatic and sometimes non-obvious ways. Although this "magic" may present few problems in a C++-only universe, it greatly complicates the problem of crossing language boundaries and provides many opportunities to shoot yourself in the foot. You will just have to be careful.

5.2 Approach

It is important to emphasize that SWIG takes a deliberately conservative and non-intrusive approach to C++ wrapping. SWIG does not encapsulate C++ classes inside special C++ adaptor or proxy classes, it does not rely upon templates, nor does it use C++ inheritance when generating wrappers. The last thing that most C++ programs need is even more compiler magic. Therefore, SWIG tries to maintain a very strict and clean separation between the implementation of your C++ application and the resulting wrapper code. You might say that SWIG has been written to follow the principle of least surprise--it does not play sneaky tricks with the C++ type system, it doesn't mess with your class hierarchies, and it doesn't introduce new semantics. Although this approach might not provide the most seamless integration with C++, it is safe, simple, portable, and debuggable.

Most of this chapter focuses on the low-level procedural interface to C++ that is used as the foundation for all language modules. Keep in mind that most target languages also provide a high-level OO interface via proxy classes. A few general details about proxies can be found at the end of this chapter. However, more detailed coverage can be found in the documentation for each target language.

5.3 Supported C++ features

• Classes.
• Constructors and destructors
• Virtual functions
• Public inheritance (including multiple inheritance)
• Static functions
• Function and method overloading.
• Operator overloading for many standard operators
• References
• Templates (including specialization and member templates).
• Pointers to members
• Namespaces

The following C++ features are not currently supported :

• Nested classes
• Overloaded versions of certain operators (new, delete, etc.)

SWIG's C++ support is an ongoing project so some of these limitations may be lifted in future releases. However, we make no promises. Also, submitting a bug report is a very good way to get problems fixed (wink).

5.4 Command line options and compilation

When wrapping C++ code, it is critical that SWIG be called with the `-c++' option. This changes the way a number of critical features such as memory management are handled. It also enables the recognition of C++ keywords. Without the -c++ flag, SWIG will either issue a warning or a large number of syntax errors if it encounters C++ code in an interface file.

When compiling and linking the resulting wrapper file, it is normal to use the C++ compiler. For example:

$ swig -c++ -tcl example.i
$ c++ -c example_wrap.cxx 
$ c++ example_wrap.o $(OBJS) -o example.so

5.5 Simple C++ wrapping

%module list
%{
#include "list.h"
%}

// Very simple C++ example for linked list

class List {
public:
  List();
  ~List();
  int  search(char *value);
  void insert(char *);
  void remove(char *);
  char *get(int n);
  int  length;
static void print(List *l);
};

5.5.1 Constructors and destructors

List * new_List(void) {
	return new List;
}
void delete_List(List *l) {
	delete l;
}

5.5.2 Default constructors

• A default constructor is not created if a class already defines a constructor with arguments.

• Default constructors are not generated for classes with pure virtual methods or for classes that inherit from an abstract class, but don't provide definitions for all of the pure methods.

• A default constructor is not created unless all bases classes support a default constructor.

• Default constructors and destructors are not created if a class defines constructors or destructors in a private or protected section.

• Default constructors and destructors are not created if any base class defines a private default constructor or a private destructor.

%nodefault;   // Disable creation of constructor/destructor
class Foo {
...
};
%makedefault;

%nodefault Foo;     // Disable for class Foo only.

5.5.3 When constructor wrappers aren't created

First, SWIG won't generate wrappers for protected or private constructors. For example:

class Foo {
protected:
     Foo();         // Not wrapped.
public:
      ...
};

Next, SWIG won't generate wrappers for a class if it appears to be abstract--that is, it has undefined pure virtual methods. Here are some examples:

class Bar {
public:
     Bar();               // Not wrappped.  Bar is abstract.
     virtual void spam(void) = 0; 
};

class Grok : public Bar {
public:
      Grok();            // Not wrapped. No implementation of abstract spam().
};

% swig -Wall -python module.i

%feature("notabstract") Foo;

class Foo : public Bar {
public:
     Foo();    // Generated no matter what---not abstract. 
     ...
};

5.5.4 Copy constructors

class List {
public:
    List();    
    List(const List &);      // Copy constructor
    ...
};

x = new_List()               # Create a list
y = new_List(x)              # Copy list x

List *copy_List(List *f) {
    return new List(*f);
}

Note: For a class X, SWIG only treats a constructor as a copy constructor if it can be applied to an object of type X or X *. If more than one copy constructor is defined, only the first definition that appears is used as the copy constructor--other definitions will result in a name-clash. Constructors such as X(const X &), X(X &), and X(X *) are handled as copy constructors in SWIG.

Note: SWIG does not generate a copy constructor wrapper unless one is explicitly declared in the class. This differs from the treatment of default constructors and destructors.

Compatibility note: Special support for copy constructors was not added until SWIG-1.3.12. In previous versions, copy constructors could be wrapped, but they had to be renamed. For example:

class Foo {
public:
    Foo();
  %name(CopyFoo) Foo(const Foo &);
    ...
};

5.5.5 Member functions

int List_search(List *obj, char *value) {
	return obj->search(value);
}

It should be noted that SWIG does not actually create a C accessor function in the code it generates. Instead, member access such as obj->search(value) is directly inlined into the generated wrapper functions. However, the name and calling convention of the wrappers match the accessor function prototype described above.

5.5.6 Static members

Usually, static members are accessed as functions with names in which the class name has been prepended with an underscore. For example, List_print.

5.5.7 Member functions and default arguments

class Foo {
public:
    void bar(int x, int y = 3);
};

class Foo {
private:
   int  spam;
public:
   void bar(int x, int y = spam);   // Illegal in SWIG. Private default value
};

example.i:15. Warning 'spam' is private in this context.
example.i:15. Warning. Can't set default argument (ignored)

There are several somewhat clumsy ways to work around this problem (which are not discussed here). However, a simpler solution may be to reconsider your design--is it really that critical to make the default argument private?

5.5.8 Member data

int List_length_get(List *obj) {
	return obj->length;
}
int List_length_set(List *obj, int value) {
	obj->length = value;
	return value;
}

class List {
public:
...
%immutable;
	int length;
%mutable;
...
};

%immutable List::length;
...
class List {
   ...
   int length;         // Immutable by above directive
   ...
};

There are some subtle issues when wrapping data members that are themselves classes. For instance, if you had another class like this,

class Foo {
public:
    List items;
    ...

List *Foo_items_get(Foo *self) {
    return &self->items;
}
void Foo_items_set(Foo *self, List *value) {
    self->items = *value;
}

Compatibility note: Read-only access used to be controlled by a pair of directives %readonly and %readwrite. Although these directives still work, they generate a warning message. Simply change the directives to %immutable; and %mutable; to silence the warning. Don't forget the extra semicolon!

Compatibility note: Prior to SWIG-1.3.12, all members of unknown type were wrapped into accessor functions using pointers. For example, if you had a structure like this

struct Foo {
   size_t  len;
};

5.6 Protection

By default, members of a class definition are assumed to be private until you explicitly give a `public:' declaration (This is the same convention used by C++).

A subtle access problem relates to default values of member functions. Specifically, default values must be public. Please go back to the section on default arguments for further details.

5.7 Enums and constants

class Swig {
public:
	enum {ALE, LAGER, PORTER, STOUT};
};

Swig_ALE = Swig::ALE
Swig_LAGER = Swig::LAGER
Swig_PORTER = Swig::PORTER
Swig_STOUT = Swig::STOUT

5.8 Friends

class Foo {
public:
     ...
     friend void blah(Foo *f);
     ...
};

class Foo {
public:
    ...
    friend void blah(Foo *f);       // Ignored
    ...
};

void blah(Foo *f);       // Generates wrappers

5.9 References and pointers

class Foo {
public:
	double bar(double &a);
}

is accessed using a function similar to this:

double Foo_bar(Foo *obj, double *a) {
	obj->bar(*a);
}

void foo(const int &x);

foo(3)              # Notice pass by value

class Bar {
public:
     Foo &spam();
};

Foo *Bar_spam(Bar *obj) {
   Foo &result = obj->spam();
   return &result;
}

const int &bar();

Don't return references to objects allocated as local variables on the stack. SWIG doesn't make a copy of the objects so this will probably cause your program to crash.

Note: The special treatment for references to primitive datatypes is necessary to provide more seamless integration with more advanced C++ wrapping applications---especially related to templates and the STL. This was first added in SWIG-1.3.12.

5.10 Pass and return by value

Vector cross_product(Vector a, Vector b);

Vector *wrap_cross_product(Vector *a, Vector *b) {
   Vector x = *a;
   Vector y = *b;
   Vector r = cross_product(x,y);
   return new Vector(r);
}

If Vector is defined as class in the interface, but it does not support a default constructor, SWIG changes the wrapper code by encapsulating the arguments inside a special C++ template wrapper class. This produces a wrapper that looks like this:

Vector cross_product(Vector *a, Vector *b) {
   SwigValueWrapper<Vector> x = *a;
   SwigValueWrapper<Vector> y = *b;
   SwigValueWrapper<Vector> r = cross_product(x,y);
   return new Vector(r);
}

Note: this transformation has no effect on typemaps or any other part of SWIG---it should be transparent except that you may see this code when reading the SWIG output file.

Note: This template transformation is new in SWIG-1.3.11 and may be refined in future SWIG releases. In practice, it is only necessary to do this for classes that don't define a default constructor.

Note: The use of this template only occurs when objects are passed or returned by value. It is not used for C++ pointers or references.

Note: The performance of pass-by-value is especially bad for large objects and should be avoided if possible (consider using references instead).

5.11 Inheritance

SWIG does not support private or protected inheritance (it is parsed, but it has no effect on the generated code). Note: private and protected inheritance do not define an "isa" relationship between classes so it would have no effect on type-checking anyways.

The following example shows how SWIG handles inheritance. For clarity, the full C++ code has been omitted.

// shapes.i
%module shapes
%{
#include "shapes.h"
%}

class Shape {
public:
        double x,y;
	virtual double area() = 0;
	virtual double perimeter() = 0;
	void    set_location(double x, double y);
};
class Circle : public Shape {
public:
	Circle(double radius);
	~Circle();
	double area();
	double perimeter();
};
class Square : public Shape {
public:
	Square(double size);
	~Square();
	double area();
	double perimeter();
}

When wrapped into Python, we can now perform the following operations :

$ python
>>> import shapes
>>> circle = shapes.new_Circle(7)
>>> square = shapes.new_Square(10)
>>> print shapes.Circle_area(circle)
153.93804004599999757
>>> print shapes.Shape_area(circle)
153.93804004599999757
>>> print shapes.Shape_area(square)
100.00000000000000000
>>> shapes.Shape_set_location(square,2,-3)
>>> print shapes.Shape_perimeter(square)
40.00000000000000000
>>>

One important point concerning inheritance is that the low-level accessor functions are only generated for classes in which they are actually declared. For instance, in the above example, the method set_location() is only accessible as Shape_set_location() and not as Circle_set_location() or Square_set_location(). Of course, the Shape_set_location() function will accept any kind of object derived from Shape. Similarly, accessor functions for the attributes x and y are generated as Shape_x_get(), Shape_x_set(), Shape_y_get(), and Shape_y_set(). Functions such as Circle_x_get() are not available--instead you should use Shape_x_get().

Although the low-level C-like interface is functional, most language modules also produce a higher level OO interface using proxy classes. This approach is described later and can be used to provide a more natural C++ interface.

Note: For the best results, SWIG requires all base classes to be defined in an interface. Otherwise, you may get an warning message like this:

example:18. Nothing known about class 'Foo'. Ignored.

Note: typedef-names can be used as base classes. For example:

class Foo {
...
};

typedef Foo FooObj;
class Bar : public FooObj {     // Ok.  Base class is Foo
...
};

typedef struct {
   ...
} Foo;

class Bar : public Foo {    // Ok. 
...
};

Compatibility Note: Starting in version 1.3.7, SWIG only generates low-level accessor wrappers for the declarations that are actually defined in each class. This differs from SWIG1.1 which used to inherit all of the declarations defined in base classes and regenerate specialized accessor functions such as Circle_x_get(), Square_x_get(), Circle_set_location(), and Square_set_location(). This behavior resulted in huge amounts of replicated code for large class hierarchies and made it awkward to build applications spread across multiple modules (since accessor functions are duplicated in every single module). It is also unnecessary to have such wrappers when advanced features like proxy classes are used. Future versions of SWIG may apply further optimizations such as not regenerating wrapper functions for virtual members that are already defined in a base class.

5.12 A brief discussion of multiple inheritance, pointers, and type checking

_808fea88_p_Circle

In general, the answer to this question is no. In the wrappers, all pointers are converted into a common data representation in the target language. Typically this is the equivalent of casting a pointer to void *. This means that any C++ type information associated with the pointer is lost in the conversion.

The problem with losing type information is that it is needed to properly support many advanced C++ features--especially multiple inheritance. For example, suppose you had code like this:

class A {
public:
   int x;
};

class B {
public:
   int y;
};

class C : public A, public B {
};

int A_function(A *a) {
   return a->x;
}

int B_function(B *b) {
   return b->y;
}

C *c = new C();
void *p = (void *) c;
...
int x = A_function((A *) p);
int y = B_function((B *) p);

             ------------    <--- (C *),  (A *)
            |     A      |
            |------------|   <--- (B *)
            |     B      |
             ------------   

The use of type tags marks all pointers with the real type of the underlying object. This extra information is then used by SWIG generated wrappers to correctly cast pointer values under inheritance (avoiding the above problem).

One might be inclined to fix this problem using some variation of dynamic_cast<>. The only problem is that it doesn't work with void pointers, it requires RTTI support, and it only works with polymorphic classes (i.e., classes that define one or more virtual functions).

The bottom line: learn to live with type-tagged pointers.

5.13 Renaming

class List {
public:
  List();
%name(ListSize) List(int maxsize);
  ~List();
  int  search(char *value); 
%name(find)    void insert(char *); 
%name(delete)  void remove(char *); 
  char *get(int n);
  int  length;
static void print(List *l);
};

The %name directive can be applied to all members including constructors, destructors, static functions, data members, and enumeration values.

The class name prefix can also be changed by specifying

%name(newname) class List {
...
}

5.14 Wrapping Overloaded Functions and Methods

void foo(int x) {
   printf("x is %d\n", x);
}
void foo(char *x) {
   printf("x is '%s'\n", x);
}

>>> foo(3)
x is 3
>>> foo("hello")
x is 'hello'
>>>

class Foo {
public:
     Foo();
     Foo(const Foo &);   // Copy constructor
     void bar(int x);
     void bar(char *s, int y);
};

>>> f = Foo()          # Create a Foo
>>> f.bar(3)
>>> g = Foo(f)         # Copy Foo
>>> f.bar("hello",2)

5.14.1 Dispatch function generation

void foo(char *x);
void foo(int x);

For statically typed languages, SWIG uses the language's method overloading mechanism. To implement overloading for the scripting languages, SWIG generates a dispatch function that checks the number of passed arguments and their types. To create this function, SWIG first examines all of the overloaded methods and ranks them according to the following rules:

1. Number of required arguments. Methods are sorted by increasing number of required arguments.

2. Argument type precedence. All C++ datatypes are assigned a numeric type precedence value (which is determined by the language module).

   Type              Precedence
   ----------------  ----------
   TYPE *            0     (High)
   void *            20
   Integers          40
   Floating point    60
   char              80
   Strings           100   (Low)
   

   Using these precedence values, overloaded methods with the same number of required arguments are sorted in increased order of precedence values.

This may sound very confusing, but an example will help. Consider the following collection of overloaded methods:

void foo(double);
void foo(int);
void foo(Bar *);
void foo();
void foo(int x, int y, int z, int w);
void foo(int x, int y, int z = 3);
void foo(double x, double y);
void foo(double x, Bar *z);

rank
-----
[0]   foo()
[1]   foo(double);
[2]   foo(int);
[3]   foo(Bar *);
[4]   foo(int x, int y, int z = 3);
[5]   foo(double x, double y)
[6]   foo(double x, Bar *z)
[7]   foo(int x, int y, int z, int w);

rank
-----
[0]   foo()
[1]   foo(Bar *);
[2]   foo(int);
[3]   foo(double);
[4]   foo(int x, int y, int z = 3);
[5]   foo(double x, Bar *z)
[6]   foo(double x, double y)
[7]   foo(int x, int y, int z, int w);

If you're still confused, don't worry about it---SWIG is probably doing the right thing.

5.14.2 Ambiguity in Overloading

void foo(int x);
void foo(long x);

example.i:4: Warning(509): Overloaded foo(long) is shadowed by foo(int) at example.i:3.

example.i:4: Warning(516): Overloaded method foo(long) ignored. Method foo(int) at example.i:3 used.

Ambiguity problems are known to arise in the following situations:

• Integer conversions. Datatypes such as int, long, and short cannot be disambiguated in some languages. Shown above.

• Floating point conversion. float and double can not be disambiguated in some languages.

• Pointers and references. For example, Foo * and Foo &.

• Pointers and arrays. For example, Foo * and Foo [4].

• Pointers and instances. For example, Foo and Foo *. Note: SWIG converts all instances to pointers.

• Qualifiers. For example, const Foo * and Foo *.

• Default vs. non default arguments. For example, foo(int a, int b) and foo(int a, int b = 3).

When wrapping an overloaded function, there is a chance that you will get an error message like this:

example.i:3: Warning(467): Overloaded foo(int) not supported (no type checking rule for 'int').

If you get an error message such as the following,

foo.i:6. Overloaded declaration ignored.  Spam::foo(double )
foo.i:5. Previous declaration is Spam::foo(int )
foo.i:7. Overloaded declaration ignored.  Spam::foo(Bar *,Spam *,int )
foo.i:5. Previous declaration is Spam::foo(int )

5.14.3 Ambiguity resolution and renaming

%ignore foo(long);

void foo(int);
void foo(long);       // Ignored.  Oh well.

%rename(foo_long) foo(long);

void foo(int);
void foo(long);       // Accessed as foo_long()

/* Forward renaming declarations */
%rename(foo_i) foo(int); 
%rename(foo_d) foo(double);
...
void foo(int);           // Becomes 'foo_i'
void foo(char *c);       // Stays 'foo' (not renamed)

class Spam {
public:
   void foo(int);      // Becomes 'foo_i'
   void foo(double);   // Becomes 'foo_d'
   ...
};

%rename(foo_i) ::foo(int);      // Only rename foo(int) in the global scope.
                                // (will not rename class members)

%rename(foo_i) Spam::foo(int);  // Only rename foo(int) in class Spam

%rename(foo_i) Spam::foo(int);
%rename(foo_d) Spam::foo(double);

class Spam {
public:
   virtual void foo(int);      // Renamed to foo_i
   virtual void foo(double);   // Renamed to foo_d
   ...
};

class Bar : public Spam {
public:
   virtual void foo(int);      // Renamed to foo_i
   virtual void foo(double);   // Renamed to foo_d
...
};

class Grok : public Bar {
public:
   virtual void foo(int);      // Renamed to foo_i
   virtual void foo(double);   // Renamed to foo_d
...
};

class Spam {
   %rename(foo_i) foo(int);
   %rename(foo_d) foo(double);
public:
   virtual void foo(int);      // Renamed to foo_i
   virtual void foo(double);   // Renamed to foo_d
   ...
};

class Bar : public Spam {
public:
   virtual void foo(int);      // Renamed to foo_i
   virtual void foo(double);   // Renamed to foo_d
...
};

A special form of %rename can be used to apply a renaming just to class members (of all classes):

%rename(foo_i) *::foo(int);   // Only rename foo(int) if it appears in a class.

Although this discussion has primarily focused on %rename all of the same rules also apply to %ignore. For example:

%ignore foo(double);          // Ignore all foo(double)
%ignore Spam::foo;            // Ignore foo in class Spam
%ignore Spam::foo(double);    // Ignore foo(double) in class Spam
%ignore *::foo(double);       // Ignore foo(double) in all classes

Notes on %rename and %ignore:

• Since, the %rename declaration is used to declare a renaming in advance, it can be placed at the start of an interface file. This makes it possible to apply a consistent name resolution without having to modify header files. For example:

  %module foo
  
  /* Rename these overloaded functions */
  %rename(foo_i) foo(int); 
  %rename(foo_d) foo(double);
  
  %include "header.h"
  

• The scope qualifier (::) can also be used on simple names. For example:

  %rename(bar) ::foo;       // Rename foo to bar in global scope only
  %rename(bar) Spam::foo;   // Rename foo to bar in class Spam only
  %rename(bar) *::foo;      // Rename foo in classes only
  

• Name matching tries to find the most specific match that is defined. A qualified name such as Spam::foo always has higher precedence than an unqualified name foo. Spam::foo has higher precedence than *::foo and *::foo has higher precedence than foo. A parameterized name has higher precedence than an unparameterized name within the same scope level. However, an unparameterized name with a scope qualifier has higher precedence than a parameterized name in global scope (e.g., a renaming of Spam::foo takes precedence over a renaming of foo(int)).

• The order in which %rename directives are defined does not matter as long as they appear before the declarations to be renamed. Thus, there is no difference between saying:

  %rename(bar) foo;
  %rename(foo_i) Spam::foo(int);
  %rename(Foo) Spam::foo;
  

  and this

  %rename(Foo) Spam::foo;
  %rename(bar) foo;
  %rename(foo_i) Spam::foo(int);
  

  (the declarations are not stored in a linked list and order has no importance). Of course, a repeated %rename directive will change the setting for a previous %rename directive if exactly the same name, scope, and parameters are supplied.

• For multiple inheritance where renaming rules are defined for multiple base classes, the first renaming rule found on a depth-first traversal of the class hierarchy is used.

• The name matching rules strictly follow member qualification rules. For example, if you have a class like this:

  class Foo {
  public:
     ...
     void bar();
     ...
  };
  

  the declaration %rename(name) Foo::bar() only applies to the unqualified member bar(). However, an often overlooked C++ feature is that classes can define two different overloaded members that differ only in their qualifiers, like this:

  class Foo {
  public:
     ...
     void bar();         // Unqualified member
     void bar() const;   // Qualified member (OK)
     ...
  };
  

  In this case, the renaming operator would only apply to the first method. If you wanted to rename the qualified member function, use %rename(name) Foo::bar() const instead. Similarly, if you merely wanted to ignore one of the declarations, use %ignore with the full qualification. For example, the following directive would tell SWIG to ignore the const version of bar() above:

  %ignore Foo::bar() const;   // Ignore bar() const, but leave other bar() alone
  

5.14.4 Comments on overloading

Internally, the overloading mechanism is completely configurable by the target language module. Therefore, the degree of overloading support may vary from language to language. As a general rule, statically typed languages like Java are able to provide more support than dynamically typed languages like Perl, Python, Ruby, and Tcl.

5.15 Wrapping overloaded operators

class Complex {
private:
  double rpart, ipart;
public:
  Complex(double r = 0, double i = 0) : rpart(r), ipart(i) { }
  Complex(const Complex &c) : rpart(c.rpart), ipart(c.ipart) { }
  Complex &operator=(const Complex &c) {
    rpart = c.rpart;
    ipart = c.ipart;
    return *this;
  }
  Complex operator+(const Complex &c) const {
    return Complex(rpart+c.rpart, ipart+c.ipart);
  }
  Complex operator-(const Complex &c) const {
    return Complex(rpart-c.rpart, ipart-c.ipart);
  }
  Complex operator*(const Complex &c) const {
    return Complex(rpart*c.rpart - ipart*c.ipart,
		   rpart*c.ipart + c.rpart*ipart);
  }
  Complex operator-() const {
    return Complex(-rpart, -ipart);
  }
  double re() const { return rpart; }
  double im() const { return ipart; }
};

Some language modules already know how to automatically handle certain operators (mapping them into operators in the target language). However, the underlying implementation of this is really managed in a very general way using the %rename directive. For example, in Python a declaration similar to this is used:

%rename(__add__) Complex::operator+;

_wrap_Complex___add__(args) {
   ... get args ...
   obj->operator+(args);
   ...
}

>>> a = Complex(3,4)
>>> b = Complex(5,2)
>>> c = a + b           # Invokes __add__ method

%rename(add) operator+;

a = Complex(3,4)
b = Complex(5,2)
c = a.add(b)      # Call a.operator+(b)

%ignore Complex::operator=;             // Ignore = in class Complex
%ignore *::operator=;                   // Ignore = in all classes
%ignore operator=;                      // Ignore = everywhere.

%rename(__sub__) Complex::operator-; 
%rename(__neg__) Complex::operator-();  // Unary - 

Handling operators in this manner is mostly straightforward. However, there are a few subtle issues to keep in mind:

• In C++, it is fairly common to define different versions of the operators to account for different types. For example, a class might also include a friend function like this:

  class Complex {
  public:
    friend Complex operator+(Complex &, double);
  };
  Complex operator+(Complex &, double);
  

  SWIG simply ignores all friend declarations. Furthermore, it doesn't know how to associate the associated operator+ with the class (because it's not a member of the class).

  It's still possible to make a wrapper for this operator, but you'll have to handle it like a normal function. For example:

  %rename(add_complex_double) operator+(Complex &, double);
  

• Certain operators are ignored by default. For instance, new and delete operators are ignored as well as conversion operators.

• The semantics of certain C++ operators may not match those in the target language.

5.16 Class extension

%module vector
%{
#include "vector.h"
%}

class Vector {
public:
	double x,y,z;
	Vector();
	~Vector();
	... bunch of C++ methods ...
	%extend {
		char *__str__() {
			static char temp[256];
			sprintf(temp,"[ %g, %g, %g ]", v->x,v->y,v->z);
			return &temp[0];
		}
	}
};

This code adds a __str__ method to our class for producing a string representation of the object. In Python, such a method would allow us to print the value of an object using the print command.

>>>
>>> v = Vector();
>>> v.x = 3
>>> v.y = 4
>>> v.z = 0
>>> print(v)
[ 3.0, 4.0, 0.0 ]
>>>

Compatibility note: The %extend directive is a new name for the %addmethods directive. Since %addmethods could be used to extend a structure with more than just methods, a more suitable directive name has been chosen.

5.17 Templates

void foo(vector<int> *a, int n);
void bar(list<int,100> *x);

void bar(list<int,100> *x);    // OK
void bar(list<int,2*50> *x);   // Illegal

typedef int Integer;
void foo(vector<int> *x, vector<Integer> *y);

Starting with SWIG-1.3.7, simple C++ template declarations can also be wrapped. SWIG-1.3.12 greatly expands upon the earlier implementation. Before discussing this any further, there are a few things you need to know about template wrapping. First, a bare C++ template does not define any sort of runnable object-code for which SWIG can normally create a wrapper. Therefore, in order to wrap a template, you need to give SWIG information about a particular template instantiation (e.g., vector<int>, array<double>, etc.). Second, an instantiation name such as vector<int> is generally not a valid identifier name in most target languages. Thus, you will need to give the template instantiation a more suitable name such as intvector when creating a wrapper.

To illustrate, consider the following template definition:

template<class T> class List {
private:
    T *data;
    int nitems;
    int maxitems;
public:
    List(int max) {
      data = new T [max];
      nitems = 0;
      maxitems = max;
    }
    ~List() {
      delete [] data;
    };
    void append(T obj) {
      if (nitems < maxitems) {
        data[nitems++] = obj;
      }
    }
    int length() {
      return nitems;
    }
    T get(int n) {
      return data[n];
    }
};

One way to create wrappers for a specific template instantiation is to simply provide an expanded version of the class directly like this:

%rename(intList) List<int>;       // Rename to a suitable identifier
class List<int> {
private:
    int *data;
    int nitems;
    int maxitems;
public:
    List(int max);
    ~List();
    void append(int obj);
    int length();
    int get(int n);
};

Since manual expansion of templates gets old in a hurry, the %template directive can be used to create instantiations of a template class. Semantically, %template is simply a shortcut---it expands template code in exactly the same way as shown above. Here are some examples:

/* Instantiate a few different versions of the template */
%template(intList) List<int>;
%template(doubleList) List<double>;

%template(intList) List<int>;
...
typedef List<int> intList;    // OK

// Function template
template<class T> T max(T a, T b) { return a > b ? a : b; }

// Make some different versions of this function
%template(maxint) max<int>;
%template(maxdouble) max<double>;

The number of arguments supplied to %template should match that in the original template definition. Template default arguments are supported. For example:

template vector<typename T, int max=100> class vector {
...
};

%template(intvec) vector<int>;           // OK
%template(vec1000) vector<int,1000>;     // OK

The %template directive should not be used to wrap the same template instantiation more than once in the same scope. This will generate an error. For example:

%template(intList) List<int>;
%template(Listint) List<int>;    // Error.   Template already wrapped.

This error is caused because the template expansion results in two identical classes with the same name. This generates a symbol table conflict. Besides, it probably more efficient to only wrap a specific instantiation only once in order to reduce the potential for code bloat.

Since the type system knows how to handle typedef, it is generally not necessary to instantiate different versions of a template for typenames that are equivalent. For instance, consider this code:

%template(intList) vector<int>;
typedef int Integer;
...
void foo(vector<Integer> *x);

When a template is instantiated using %template, information about that class is saved by SWIG and used elsewhere in the program. For example, if you wrote code like this,

...
%template(intList) List<int>;
...
class UltraList : public List<int> {
   ...
};

example.h:42. Nothing known about class 'List<int >' (ignored). 
example.h:42. Maybe you forgot to instantiate 'List<int >' using %template. 

If a template class inherits from another template class, you need to make sure that base classes are instantiated before derived classes. For example:

template<class T> class Foo {
...
};

template<class T> class Bar : public Foo<T> {
...
};

// Instantiate base classes first 
%template(intFoo) Foo<int>;
%template(doubleFoo) Foo<double>;

// Now instantiate derived classes
%template(intBar) Bar<int>;
%template(doubleBar) Bar<double>;

Occassionally, you may need to tell SWIG about base classes that are defined by templates, but which aren't supposed to be wrapped. Since SWIG is not able to automatically instantiate templates for this purpose, you must do it manually. To do this, simply use %template with no name. For example:

// Instantiate traits<double,double>, but don't wrap it.
%template() traits<double,double>;

If you have to instantiate a lot of different classes for many different types, you might consider writing a SWIG macro. For example:

%define TEMPLATE_WRAP(T,prefix) 
%template(prefix ## Foo) Foo<T>;
%template(prefix ## Bar) Bar<T>;
...
%enddef

TEMPLATE_WRAP(int, int)
TEMPLATE_WRAP(double, double)
TEMPLATE_WRAP(char *, String)
...

The SWIG template mechanism does support specialization. For instance, if you define a class like this,

template<> class List<int> {
private:
    int *data;
    int nitems;
    int maxitems;
public:
    List(int max);
    ~List();
    void append(int obj);
    int length();
    int get(int n);
};

Partial template specialization is partially supported by SWIG. For example, this code defines a template that is applied when the template argument is a pointer.

template<class T> class List<T*> {
private:
    T *data;
    int nitems;
    int maxitems;
public:
    List(int max);
    ~List();
    void append(int obj);
    int length();
    T get(int n);
};

template<class T1, class T2> class Foo<T1, T2 *> { };

Member function templates are supported. The underlying principle is the same as for normal templates--SWIG can't create a wrapper unless you provide more information about types. For example, a class with a member template might look like this:

class Foo {
public:
     template<class T> void bar(T x, T y) { ... };
     ...
};

class Foo {
public:
     template<class T> void bar(T x, T y) { ... };
     ...
     %template(barint)    bar<int>;
     %template(bardouble) bar<double>;
};

class Foo {
public:
     template<class T> void bar(T x, T y) { ... };
     ...
};
...
%extend Foo {
     %template(barint)    bar<int>;
     %template(bardouble) bar<double>;
};

When used with members, the %template directive may be placed in another template class. Here is a slightly perverse example:

// A template
template<class T> class Foo {
public:
     // A member template
     template<class S> T bar(S x, S y) { ... };
     ...
};

// Expand a few member templates
%extend Foo {
     %template(bari) bar<int>;
     %template(bard) bar<double>;
};

// Create some wrappers for the template
%template(Fooi) Foo<int>;
%template(Food) Foo<double>;

A common use of member templates is to define constructors for copies and conversions. For example:

template<class T1, class T2> struct pair {
   T1 first;
   T2 second;
   pair() : first(T1()), second(T2()) { }
   pair(const T1 &x, const T2 &y) : first(x), second(y) { }
   template<class U1, class U2> pair(const pair<U1,U2> &x) : first(x.first),second(x.second) { }
};

%extend pair {
   %template(pair) pair<T1,T2>;        // Generate default copy constructor
};

Alternatively, you could expand the constructor template in selected instantiations. For example:

// Instantiate a few versions
%template(pairii) pair<int,int>;
%template(pairdd) pair<double,double>;

// Create a conversion constructor from int to double
%extend pair<double,double> {
   %template(pairdd_from_pairii) pair<int,int>;   // Conversion constructor
};

If all of this isn't quite enough and you really want to make someone's head explode, SWIG directives such as %rename, %extend, and %typemap can be included directly in template definitions. For example:

// File : list.h
template<class T> class List {
   ...
public:
    %rename(__getitem__) get(int);
    List(int max);
    ~List();
    ...
    T get(int index);
    %extend {
        char *__str__() {
            /* Make a string representation */
            ...
        }
    }
};

It is also possible to separate these declarations from the template class. For example:

%rename(__getitem__) List::get;
%extend List {
    char *__str__() {
        /* Make a string representation */
        ...
    }
    /* Make a copy */
    T *__copy__() {
       return new List<T>(*self);
    }
};

...
template<class T> class List {
   ...
   public:
   List() { };
   ...
};

When %extend is decoupled from the class definition, it is legal to use the same template parameters as provided in the class definition. These are replaced when the template is expanded. In addition, the %extend directive can be used to add additional methods to a specific instantiation. For example:

%template(intList) List<int>;

%extend List<int> {
    void blah() {
          printf("Hey, I'm an List<int>!\n");
    }
};

Needless to say, SWIG's template support provides plenty of opportunities to break the universe. That said, an important final point is that SWIG does not perform extensive error checking of templates! Specifically, SWIG does not perform type checking nor does it check to see if the actual contents of the template declaration make any sense. Since the C++ compiler will hopefully check this when it compiles the resulting wrapper file, there is no practical reason for SWIG to duplicate this functionality (besides, none of the SWIG developers are masochistic enough to want to implement this right now).

Finally, there are a few limitations in SWIG's current support for templates:

• SWIG does not support overloaded versions of a template. Some C++ programs might do this to define overloaded functions. For example:

  template<class T> void foo(T x) { };
  template<class T> void foo(T x, T y) { };     // Error. foo already defined.
  

  This will generate a name conflict error message in SWIG. To silence the error message, use %ignore:

  %ignore foo(T,T);
  

  In this case, %template will only work with the first definition. To create a wrapper for the second definition, just do it manually:

  %name(foo2int) void foo<int>(int x, int y);
  

Compatibility Note: The first implementation of template support relied heavily on macro expansion in the preprocessor. Templates have been more tightly integrated into the parser and type system in SWIG-1.3.12 and the preprocessor is no longer used. Code that relied on preprocessing features in template expansion will no longer work. However, SWIG still allows the # operator to be used to generate a string from a template argument.

Compatibility Note: In earlier versions of SWIG, the %template directive introduced a new class name. This name could then be used with other directives. For example:

%template(vectori) vector<int>;
%extend vectori {
    void somemethod() { }
};

%template(vectori) vector<int>;
%extend vector<int> {
    void somemethod() { }
};

5.18 Namespaces

namespace math {
   double sin(double);
   double cos(double);

   class Complex {
      double im,re;
   public:
      ...
   };
   ...
};

double x = math::sin(1.0);
double magitude(math::Complex *c);
math::Complex c;
...

using math::Complex;
double magnitude(Complex *c);       // Namespace prefix stripped

using namespace math;
double x = sin(1.0);
double magnitude(Complex *c);

namespace M = math;
double x = M::sin(1.0);
double magnitude(M::Complex *c);

namespace A {
  class Foo {
  };
}

namespace B {
   namespace C {
      using namespace A;
   }
   typedef C::Foo FooClass;
}

namespace BIGB = B;

namespace D {
   using BIGB::FooClass;
   class Bar : public FooClass {
   }
};

class Spam : public D::Bar {
};

void evil(A::Foo *a, B::FooClass *b, B::C::Foo *c, BIGB::FooClass *d,
          BIGB::C::Foo *e, D::FooClass *f);

SWIG fully supports C++ namespaces in its internal type system and class handling code. If you feed SWIG the above code, it will be parsed correctly, it will generate compilable wrapper code, and it will produce a working scripting language module. However, the default wrapping behavior is to flatten namespaces in the target language. This means that the contents of all namespaces are merged together in the resulting scripting language module. For example, if you have code like this,

%module foo
namespace foo {
   void bar(int);
   void spam();
}

namespace bar {
   void blah();
}

There is some rationale for taking this approach. Since C++ namespaces are often used to define modules in C++, there is a natural correlation between the likely contents of a SWIG module and the contents of a namespace. For instance, it would not be unreasonable to assume that a programmer might make a separate extension module for each C++ namespace. In this case, it would be redundant to prepend everything with an additional namespace prefix when the module itself already serves as a namespace in the target language. Or put another way, if you want SWIG to keep namespaces separate, simply wrap each namespace with its own SWIG interface.

Because namespaces are flattened, it is possible for symbols defined in different namespaces to generate a name conflict in the target language. For example:

namespace A {
   void foo(int);
}
namespace B {
   void foo(double);
}

example.i:26. Error. 'foo' is multiply defined in the generated module.
example.i:23. Previous declaration of 'foo'

%rename(B_foo) B::foo;
...
namespace A {
   void foo(int);
}
namespace B {
   void foo(double);     // Gets renamed to B_foo
}

using declarations do not have any effect on the generated wrapper code. They are ignored by SWIG language modules and they do not result in any code. However, these declarations are used by the internal type system to track type-names. Therefore, if you have code like this:

namespace A {
   typedef int Integer;
}
using namespace A;
void foo(Integer x);

Namespaces may be combined with templates. If necessary, the %template directive can be used to expand a template defined in a different namespace. For example:

namespace foo {
    template<typename T> max(T a, T b) { return a > b ? a : b; }
}

using foo::max;

%template(maxint)   max<int>            // Okay.
%template(maxfloat) foo::max<float>;    // Okay (qualified name).

namespace bar {
    using namespace foo;
    %template(maxdouble)  max<double>;    // Okay.
}

namespace foo {
    typedef int Integer;
    class bar {
    public:
       ...
    };
}

%extend foo::bar {
   Integer add(Integer x, Integer y) {
       Integer r = x + y;        // Error. Integer not defined in this scope
       return r;
   }
};

%extend foo::bar {
   Integer add(Integer x, Integer y) {
       foo::Integer r = x + y;        // Ok.
       return r;
   }
};

Note: SWIG does not propagate using declarations to the resulting wrapper code. If these declarations appear in an interface, they should also appear in any header files that might have been included in a %{ ... %} section. In other words, don't insert extra using declarations into a SWIG interface unless they also appear in the underlying C++ code.

Note: Code inclusion directives such as %{ ... %} or %inline %{ ... %} should not be placed inside a namespace declaration. The code emitted by these directives will not be enclosed in a namespace and you may get very strange results. If you need to use namespaces with these directives, consider the following:

// Good version
%inline %{
namespace foo {
     void bar(int) { ... }
     ...
}
%}

// Bad version.  Emitted code not placed in namespace.
namespace foo {
%inline %{
     void bar(int) { ... }   /* I'm bad */
     ...
%}
}

Note: When the %extend directive is used inside a namespace, the namespace name is included in the generated functions. For example, if you have code like this,

namespace foo {
   class bar {
   public:
        %extend {
           int blah(int x);
        };
   };
}

Note: Although namespaces are flattened in the target language, the SWIG generated wrapper code observes the same namespace conventions as used in the input file. Thus, if there are no symbol conflicts in the input, there will be no conflicts in the generated code.

Note: Namespaces have a subtle effect on the wrapping of conversion operators. For instance, suppose you had an interface like this:

namespace foo {
   class bar;
   class spam {
   public;
        ...
        operator bar();      // Conversion of spam -> bar
        ...
   };
}

%rename(tofoo) foo::spam::operator bar();

%rename(tofoo) foo::spam::operator foo::bar();

Note: The flattening of namespaces is only intended to serve as a basic namespace implementation. Since namespaces are a new addition to SWIG, none of the target language modules are currently programmed with any namespace awareness. In the future, language modules may or may not provide more advanced namespace support.

5.19 Exception specifiers

class Error { };

class Foo {
public:
    ...
    void blah() throw(Error);
    ...
};

f = Foo()
try:
    f.blah()
except Error,e:
     # e is a wrapped instance of "Error"

Since exception specifiers are sometimes only used sparingly, this alone may not be enough to properly handle C++ exceptions. To do that, a different set of special SWIG directives are used. Consult the "Customization features" chapter for details.

5.20 Pointers to Members

double do_op(Object *o, double (Object::*callback)(double,double));
extern double (Object::*fooptr)(double,double);
%constant double (Object::*FOO)(double,double) = &Object::foo;

When pointers to members are supported, the pointer value might appear as a special string like this:

>>> print example.FOO
_ff0d54a800000000_m_Object__f_double_double__double
>>>

SWIG's type-checking mechanism is also more limited when working with member pointers. Normally SWIG tries to keep track of inheritance when checking types. However, no such support is currently provided for member pointers.

5.21 Smart pointers and operator->()

// Smart-pointer class
template<class T> class SmartPtr {
    T *pointee;
public:
    ...
    T *operator->() {
        return pointee;
    }
    ...
};

// Ordinary class
class Foo_Impl {
public:
    int x;
    virtual void bar();
    ...
};

// Smart-pointer wrapper
typedef SmartPtr<Foo_Impl> Foo;

// Create smart pointer Foo
Foo make_Foo() {
    return SmartPtr(new Foo_Impl());
}

// Do something with smart pointer Foo
void do_something(Foo f) {
    printf("x = %d\n", f->x);
    f->bar();
}

f->x
f->bar()

(f.operator->())->x;
(f.operator->())->bar();

int Foo_x_get(Foo *f) {
   return (*f)->x;
}
void Foo_x_set(Foo *f, int value) {
   (*f)->x = value;
}
void Foo_bar(Foo *f) {
   (*f)->bar();
}

The end result is that access looks very similar to C++. For example, you could do this in Python:

>>> f = make_Foo()
>>> print f.x
0
>>> f.bar()
>>>

• Only member variables and methods are wrapped through a smart pointer. Static members, enumerations, constructors, and destructors are not wrapped.

• If the smart-pointer class and the underlying object both define a method or variable of the same name, then the smart-pointer version has precedence. For example, if you have this code

  class Foo {
  public:
      int x;
  };
  
  class Bar {
  public:
      int x;       
      Foo *operator->();
  };
  

  then the wrapper for Bar::x accesses the x defined in Bar, and not the x defined in Foo.

%ignore Foo;
class Foo {       // Ignored
};

class Bar {
public:
   Foo *operator->();
   ...
};

Note: When a class defines operator->(), the operator itself is wrapped as a method __deref__(). For example:

f = Foo()               # Smart-pointer
p = f.__deref__()       # Raw pointer from operator->

Note: To disable the smart-pointer behavior, use %ignore to ignore operator->(). For example:

%ignore Bar::operator->;

Note: Smart pointer support was first added in SWIG-1.3.14.

5.22 Using declarations and inheritance

class Foo {
public:
      int  blah(int x);
};

class Bar {
public:
      double blah(double x);
};

class FooBar : public Foo, public Bar {
public:
      using Foo::blah;  
      using Bar::blah;
      char *blah(const char *x);
};

FooBar *f;
f->blah(3);         // Ok. Invokes Foo::blah(int)
f->blah(3.5);       // Ok. Invokes Bar::blah(double)
f->blah("hello");   // Ok. Invokes FooBar::blah(const char *);

>>> import example
>>> f = example.FooBar()
>>> f.blah(3)
>>> f.blah(3.5)
>>> f.blah("hello")

class Foo {
protected:
    int x;
    int blah(int x);
};

class Bar : public Foo {
public:
    using Foo::x;       // Make x public
    using Foo::blah;    // Make blah public
};

When using declarations are used as shown in these examples, declarations from the base classes are copied into the derived class and wrapped normally. When copied, the declarations retain any properties that might have been attached using %rename, %ignore, or %feature. Thus, if a method is ignored in a base class, it will also be ignored by a using declaration.

Because a using declaration does not provide fine-grained control over the declarations that get imported, it may be difficult to manage such declarations in applications that make heavy use of SWIG customization features. If you can't get using to work correctly, you can always change the interface to the following:

class FooBar : public Foo, public Bar {
public:
#ifndef SWIG
      using Foo::blah;  
      using Bar::blah;
#else
      int blah(int x);         // explicitly tell SWIG about other declarations
      double blah(double x);
#endif

      char *blah(const char *x);
};

• If a derived class redefines a method defined in a base class, then a using declaration won't cause a conflict. For example:

  class Foo {
  public:
         int blah(int );
         double blah(double);
  };
  
  class Bar : public Foo {
  public:
         using Foo::blah;    // Only imports blah(double);
         int blah(int);
  };
  

• Resolving ambiguity in overloading may prevent declarations from being imported by using. For example:

  %rename(blah_long) Foo::blah(long);
  class Foo {
  public:
       int blah(int);
       long blah(long);  // Renamed to blah_long
  };
  
  class Bar : public Foo {
  public:
       using Foo::blah;     // Only imports blah(int)
       double blah(double x);
  };
  

5.23 Partial class definitions

class Foo {
public:
#ifndef SWIG
   class Bar {
   public:
     ...
   };
#endif
   Foo();
  ~Foo();
   ...
};

Also, as a rule of thumb, SWIG should not be used on raw C++ source files.

5.24 A brief rant about const-correctness

Although SWIG knows how to correctly deal with const in its internal type system and it knows how to generate wrappers that are free of const-related warnings, SWIG does not make any attempt to preserve const-correctness in the target language. Thus, it is possible to pass const qualified objects to non-const methods and functions. For example, consider the following code in C++:

const Object * foo();
void bar(Object *);

...
// C++ code
void blah() {
   bar(foo());         // Error: bar discards const
};

>>> bar(foo())         # Okay
>>> 

The bottom line is that this particular issue does not appear to be a problem for most SWIG projects. Of course, you might want to consider using another tool if maintaining constness is the most important part of your project.

5.25 Proxy classes

5.25.1 Construction of proxy classes

class Foo {
public:
      Foo();
     ~Foo();
      int  bar(int x);
      int  x;
};

class FooProxy {
private:
      Foo    *self;
public:
      FooProxy() {
            self = new_Foo();
      }
     ~FooProxy() {
            delete_Foo(self);
      }
      int bar(int x) {
            return Foo_bar(self,x);
      }
      int x_get() {
            return Foo_x_get(self);
      }
      void x_set(int x) {
            Foo_x_set(self,x);
      }
};

class Foo:
    def __init__(self):
         self.this = new_Foo()
    def __del__(self):
         delete_Foo(self.this)
    def bar(self,x):
         return Foo_bar(self.this,x)
    def __getattr__(self,name):
         if name == 'x':
              return Foo_x_get(self.this)
         ...
    def __setattr__(self,name,value):
         if name == 'x':
              Foo_x_set(self.this,value)
         ...

Whenever possible, proxies try to take advantage of language features that are similar to C++. This might include operator overloading, exception handling, and other features.

5.25.2 Resource management in proxies

class Foo {
public:
      Foo();
     ~Foo();
      int bar(int x);
      int x;
};

class Spam {
public:
      Foo *value;
      ...
};

f = Foo()               # Creates a new Foo
s = Spam()              # Creates a new Spam
s.value = f             # Stores a reference to f inside s
g = s.value             # Returns stored reference
g = 4                   # Reassign g to some other value
del f                   # Destroy f 

Finally, consider what happens when objects are destroyed. In the statement, g=4, the variable g is reassigned. In many languages, this makes the old value of g available for garbage collection. Therefore, this causes one of the proxy classes to be destroyed. Later on, the statement del f destroys the other proxy class. Of course, there is still a reference to the original object stored inside another C++ object. What happens to it? Is it the object still valid?

To deal with memory management problems, proxy classes always provide an API for controlling ownership. In C++ pseudocode, ownership control might look roughly like this:

class FooProxy {
public:
      Foo    *self;
      int     thisown;

      FooProxy() {
            self = new_Foo();
            thisown = 1;       // Newly created object
      }
     ~FooProxy() {
            if (thisown) delete_Foo(self);
      }
      ...
      // Ownership control API
      void disown() {
           thisown = 0;
      }
      void acquire() {
           thisown = 1;
      }
};

class FooPtrProxy: public FooProxy {
public:
      FooPtrProxy(Foo *s) {
          self = s;
          thisown = 0;
      }
};

class SpamProxy {
     ...
     FooProxy *value_get() {
          return FooPtrProxy(Spam_value_get(self));
     }
     void value_set(FooProxy *v) {
          Spam_value_set(self,v->self);
          v->disown();
     }
     ...
};

• Each proxy class keeps an extra flag to indicate ownership. C++ objects are only destroyed if the ownership flag is set.

• When new objects are created in the target language, the ownership flag is set.

• When a reference to an internal C++ object is returned, it is wrapped by a proxy class, but the proxy class does not have ownership.

• In certain cases, ownership is adjusted. For instance, when a value is assigned to the member of a class, ownership is lost.

• Manual ownership control is provided by special disown() and acquire() methods.

5.25.3 Language specific details

5.26 Where to go for more information