@@ -761,7 +767,7 @@ char *cdata_name(type* ptr, int nitems) Clearly they are unsafe.
-@@ -1365,7 +1371,7 @@ structure or class instead.
@@ -1728,6 +1734,9 @@ Any thrown STL exceptions will then be gracefully handled instead of causing a c
Some target languages have support for handling the shared_ptr reference counted smart pointer. This smart pointer is available in the standard C++11 library as std::shared_ptr. @@ -1821,8 +1830,11 @@ System.out.println(val1 + " " + val2);
-This shared_ptr library works quite differently to SWIG's normal, but somewhat limited, +The shared_ptr library works quite differently to SWIG's normal, but somewhat limited, smart pointer handling. The shared_ptr library does not generate extra wrappers, just for smart pointer handling, in addition to the proxy class. The normal proxy class including inheritance relationships is generated as usual. @@ -1900,7 +1912,7 @@ Adding the missing %shared_ptr macros will fix this:
-%include "boost_shared_ptr.i" +%include <boost_shared_ptr.i> %shared_ptr(GrandParent); %shared_ptr(Parent); %shared_ptr(Child); @@ -1909,8 +1921,52 @@ Adding the missing %shared_ptr macros will fix this:
-Note: There is somewhat limited support for %shared_ptr and the director feature +The %shared_ptr macro should be used for all the required instantiations +of the template before each of the %template instantiations. +For example, consider number.h containing the following illustrative template: +
+ +
+#include <memory>
+
+template<int N> struct Number {
+ int num;
+ Number() : num(N) {}
+ static std::shared_ptr<Number<N>> make() { return std::make_shared<Number<N>>(); }
+};
+
++The SWIG code below shows the required ordering: +
+ +
+%include <std_shared_ptr.i>
+
+%shared_ptr(Number<10>);
+%shared_ptr(Number<42>);
+
+%{
+ #include "number.h"
+%}
+%include "number.h"
+
+%template(Number10) Number<10>;
+%template(Number42) Number<42>;
+
++There is somewhat limited support for %shared_ptr and the director feature and the degrees of success varies among the different target languages. Please help to improve this support by providing patches with improvements.
diff --git a/Doc/Manual/SWIG.html b/Doc/Manual/SWIG.html index de9e2ec31..d677a223f 100644 --- a/Doc/Manual/SWIG.html +++ b/Doc/Manual/SWIG.html @@ -3303,11 +3303,27 @@ Vector *new_Vector() { return (Vector *) malloc(sizeof(Vector)); } %} --The %inline directive inserts all of the code that follows +This is the same as writing: +
+ +
+%{
+/* Create a new vector */
+Vector *new_Vector() {
+ return (Vector *) malloc(sizeof(Vector));
+}
+%}
+
+/* Create a new vector */
+Vector *new_Vector() {
+ return (Vector *) malloc(sizeof(Vector));
+}
++In other words, the %inline directive inserts all of the code that follows verbatim into the header portion of an interface file. The code is then parsed by both the SWIG preprocessor and parser. Thus, the above example creates a new command new_Vector using only one @@ -3315,6 +3331,11 @@ declaration. Since the code inside an %inline %{ ... %} block is given to both the C compiler and SWIG, it is illegal to include any SWIG directives inside a %{ ... %} block.
+ ++Note: The usual SWIG C preprocessor rules apply to code in %apply blocks when SWIG parses this code. For example, as mentioned earlier, SWIG's C Preprocessor does not follow #include directives by default. +
+