959e627208
The scoping rules around %template have been specified and enforced.
The %template directive for a class template is the equivalent to an
explicit instantiation of a C++ class template. The scope for a valid
%template instantiation is now the same as the scope required for a
valid explicit instantiation of a C++ template. A definition of the
template for the explicit instantiation must be in scope where the
instantiation is declared and must not be enclosed within a different
namespace.
For example, a few %template and explicit instantiations of std::vector
are shown below:
// valid
namespace std {
%template(vin) vector<int>;
template class vector<int>;
}
// valid
using namespace std;
%template(vin) vector<int>;
template class vector<int>;
// valid
using std::vector;
%template(vin) vector<int>;
template class vector<int>;
// ill-formed
namespace unrelated {
using std::vector;
%template(vin) vector<int>;
template class vector<int>;
}
// ill-formed
namespace unrelated {
using namespace std;
%template(vin) vector<int>;
template class vector<int>;
}
// ill-formed
namespace unrelated {
namespace std {
%template(vin) vector<int>;
template class vector<int>;
}
}
// ill-formed
namespace unrelated {
%template(vin) std::vector<int>;
template class std::vector<int>;
}
When the scope is incorrect, an error now occurs such as:
cpp_template_scope.i:34: Error: 'vector' resolves to 'std::vector' and
was incorrectly instantiated in scope 'unrelated' instead of within scope 'std'.
Previously SWIG accepted the ill-formed examples above but this led to
numerous subtle template scope problems especially in the presence of
using declarations and using directives as well as with %feature and %typemap.
Actually, a valid instantiation is one which conforms to the C++03
standard as C++11 made a change to disallow using declarations and
using directives to find a template.
// valid C++03, ill-formed C++11
using std::vector;
template class vector<int>;
Similar fixes for defining classes using forward class references have
also been put in place. For example:
namespace Space1 {
struct A;
}
namespace Space2 {
struct Space1::A {
void x();
}
}
will now error out with:
cpp_class_definition.i:5: Error: 'Space1::A' resolves to 'Space1::A' and
was incorrectly instantiated in scope 'Space2' instead of within scope 'Space1'.
|
||
|---|---|---|
| .. | ||
| android | ||
| chicken | ||
| contract | ||
| csharp | ||
| d | ||
| go | ||
| guile | ||
| java | ||
| javascript | ||
| lua | ||
| modula3 | ||
| mzscheme | ||
| ocaml | ||
| octave | ||
| perl5 | ||
| php | ||
| php5 | ||
| pike | ||
| python | ||
| r | ||
| ruby | ||
| s-exp | ||
| scilab | ||
| tcl | ||
| test-suite | ||
| xml | ||
| index.html | ||
| Makefile.in | ||
| README | ||
SWIG Examples
The subdirectories of "Examples" named after SWIG's language backends
contain a number of simple examples that are primarily used for testing.
The file 'index.html' is the top of a hyperlinked document that
contains information about all of the examples along with various
notes related to each example.
Note: All of the examples rely upon the Makefile in this directory.
You may need to edit it to reflect the configuration of your machine
in case the configure script guesses incorrect settings.
*** Special note concerning C++ ***
The configure script is currently unable to handle all of the possible
options for producing dynamically loadable C++ extensions. Here are
the rules of thumb for making C++ work:
- Try using the C++ as the linker for the shared library. For example:
g++ -shared $(OBJS) -o module.so
- If that doesn't work, you may need to explicitly link against some
kind of C++ runtime library. For example:
ld -G $(OBJS) -L/opt/SUNWspro/lib -lCrun -o module.so
This can be set by modifying the setting of CPP_DLLIBS in the
Makefile.
*** Special note for SWIG Maintainers ***
When you add an example, consider arranging for the example to be also
useful as part of the SWIG testing framework. To do this, include in
the example makefile a target "check" ("check: all" is sufficient for a
first pass), and add an invocation to ../Makefile.in under target
"check-examples" (or whatever is appropriate). Later, we can add or
expand the actions under target "check" to do more in-depth testing.