~ubuntu-branches/ubuntu/oneiric/swig1.3/oneiric

<li><a href="#SWIGPlus_class_extension">Class extension</a>

<li><a href="#SWIGPlus_renaming_templated_types_namespaces">Renaming templated types in namespaces</a>

<li>A default constructor is not created unless all base classes support a 

spirit, and target language capabilities, as possible. In most

every single module).  It is also unnecessary to have such wrappers

Currently no resolution is performed in order to match function parameters. This means function parameter types must match exactly.

For example, namespace qualifiers and typedefs will not work. The following usage of typedefs demonstrates this:

 

<div class="code">

<pre>

typedef int Integer;

 

%rename(foo_i) foo(int);

 

class Spam {

public:

   void foo(Integer);  // Stays 'foo' (not renamed)

};

class Ham {

public:

   void foo(int);      // Renamed to foo_i

};

</pre>

</div>

 

<li><p>

<H2><a name="SWIGPlus_class_extension"></a>6.17 Class extension</H2>

Note that the members dereferenced by <tt>$self</tt> must be public members as the code is ultimately generated

into a global function and so will not have any access to non-public members.

    $self-&gt;Base::method(v); // akin to this-&gt;Base::method(v);

    $self-&gt;value = v;       // akin to this-&gt;value = v;

There are some restrictions on the use of non-type arguments.  Simple literals

are supported, and so are some constant expressions.  However, use of '&lt;'

and '&gt;' within a constant expressions currently is not supported by SWIG

('&lt;=' and '&gt;=' are though).  For example:

void bar(list&lt;int,100&gt; *x);                // OK

void bar(list&lt;int,2*50&gt; *x);               // OK

void bar(list&lt;int,(2&gt;1 ? 100 : 50)&gt; *x)    // Not supported

Note the use of a vararg macro for the type T. If this wasn't used, the comma in the templated type in the last example would not be possible.

    ...

    public:

    List() { };

    T get(int index);

    ...

<b>Note:</b> In the same way that no resolution is performed on parameters, a conversion operator name must match exactly to how it is defined. Do not change the qualification of the operator. For example, suppose you had an interface like this:

The following is how the feature is expected to be written for a successful match:

The following does not work as no namespace resolution is performed in the matching of conversion operator names:

Note, however, that if the operator is defined using a qualifier in its name, then the feature must use it too...

</p>

 

<div class="code">

<pre>

%rename(tofoo) foo::spam::operator bar();      // will not match

%rename(tofoo) foo::spam::operator foo::bar(); // will match

namespace foo {

   class bar;

   class spam {

   public:

        ...

        operator foo::bar();

        ...

   };

}

</pre>

</div>

 

<p>

<b>Compatibility Note:</b> Versions of SWIG prior to 1.3.32 were inconsistent in this approach. A fully qualified name was usually required, but would not work in some situations.

</p>

 

 

<p>

a basic namespace implementation.  

None of the target language modules are currently programmed

<H2><a name="SWIGPlus_renaming_templated_types_namespaces"></a>6.20 Renaming templated types in namespaces</H2>

 

 

<p>

As has been mentioned, when %rename includes parameters, the parameter types must match exactly (no typedef or namespace resolution is performed).

SWIG treats templated types slightly differently and has an additional matching rule so unlike non-templated types, an exact match is not always required.

If the fully qualified templated type is specified, it will have a higher precedence over the generic template type.

In the example below, the generic template type is used to rename to <tt>bbb</tt> and the fully qualified type is used to rename to <tt>ccc</tt>.

</p>

 

<div class="code">

<pre>

%rename(bbb) Space::ABC::aaa(T t);                       // will match but with lower precedence than ccc

%rename(ccc) Space::ABC&lt;Space::XYZ&gt;::aaa(Space::XYZ t);  // will match but with higher precedence than bbb

 

namespace Space {

  class XYZ {};

  template&lt;typename T&gt; struct ABC {

    void aaa(T t) {}

  };

}

%template(ABCXYZ) Space::ABC&lt;Space::XYZ&gt;;

</pre>

</div>

 

<p>

It should now be apparent that there are many ways to achieve a renaming with %rename. This is demonstrated

by the following two examples, which are effectively the same as the above example.

Below shows how %rename can be placed inside a namespace.

</p>

 

<div class="code">

<pre>

namespace Space {

  %rename(bbb) ABC::aaa(T t);                       // will match but with lower precedence than ccc

  %rename(ccc) ABC&lt;Space::XYZ&gt;::aaa(Space::XYZ t);  // will match but with higher precedence than bbb

  %rename(ddd) ABC&lt;Space::XYZ&gt;::aaa(XYZ t);         // will not match

}

 

namespace Space {

  class XYZ {};

  template&lt;typename T&gt; struct ABC {

    void aaa(T t) {}

  };

}

%template(ABCXYZ) Space::ABC&lt;Space::XYZ&gt;;

</pre>

</div>

 

<p>

Note that <tt>ddd</tt> does not match as there is no namespace resolution for parameter types and the fully qualified type must be specified for template type expansion.

The following example shows how %rename can be placed within %extend.

</p>

 

<div class="code">

<pre>

namespace Space {

  %extend ABC {

    %rename(bbb) aaa(T t);           // will match but with lower precedence than ccc

  }

  %extend ABC&lt;Space::XYZ&gt; {

    %rename(ccc) aaa(Space::XYZ t);  // will match but with higher precedence than bbb

    %rename(ddd) aaa(XYZ t);         // will not match

  }

}

 

namespace Space {

  class XYZ {};

  template&lt;typename T&gt; struct ABC {

    void aaa(T t) {}

  };

}

%template(ABCXYZ) Space::ABC&lt;Space::XYZ&gt;;

</pre>

</div>

 

 

<H2><a name="SWIGPlus_exception_specifications"></a>6.21 Exception specifications</H2>

<H2><a name="SWIGPlus_catches"></a>6.22 Exception handling with %catches</H2>

<H2><a name="SWIGPlus_nn33"></a>6.23 Pointers to Members</H2>

<H2><a name="SWIGPlus_nn34"></a>6.24 Smart pointers and operator-&gt;()</H2>

<H2><a name="SWIGPlus_nn35"></a>6.25 Using declarations and inheritance</H2>

<H2><a name="SWIGPlus_nested_classes"></a>6.26 Nested classes</H2>

<H2><a name="SWIGPlus_nn37"></a>6.27 A brief rant about const-correctness</H2>

<H2><a name="SWIGPlus_nn42"></a>6.28 Where to go for more information</H2>