XS-MLVP
/
swig
mirror of https://github.com/swig/swig
5
0
Fork 0
Code Issues Packages Projects Releases Wiki Activity

Doc corrections for %shared_ptr and enhancements for %inline

This commit is contained in:
William S Fulton 2017-09-15 19:21:26 +01:00
parent ce96d1b153
commit 9671613372
2 changed files with 45 additions and 16 deletions
Show Stats Download Patch File Download Diff File Expand all files Collapse all files

36
Doc/Manual/Library.html
View File

@ -1923,30 +1923,42 @@ Adding the missing <tt>%shared_ptr</tt> macros will fix this:
<H4><a name="Library_shared_ptr_templates">9.4.4.3 shared_ptr and templates</a></H4>
<p>
The <tt>%shared_ptr</tt> macro should be used for all the required instantiations
of the template before each of the <tt>%template</tt> instantiations.
For example, consider <tt>number.h</tt> containing the following illustrative template:
</p>
<div class="code">
<pre>
#include &lt;memory&gt;
template&lt;int N&gt; struct Number {
int num;
Number() : num(N) {}
static std::shared_ptr&lt;Number&lt;N&gt;&gt; make() { return std::make_shared&lt;Number&lt;N&gt;&gt;(); }
};
</pre>
</div>
<p>
Only the single <tt>%shared_ptr</tt> declaration should be used for all specializations
of the template before the first template instantiation using the following notation:
<tt>%shared_ptr(TemplateName&lt;&gt;)</tt>. For example:
The SWIG code below shows the required ordering:
</p>
<div class="code">
<pre>
%include &lt;std_shared_ptr.i&gt;
%shared_ptr(Graph&lt;&gt;); // Declaration of the transparent shared ptr for the Graph template
%shared_ptr(Number&lt;10&gt;);
%shared_ptr(Number&lt;42&gt;);
%{
#include "graph.h" // Graph definition (inside the namespace gany)
using namespace gany;
#include "number.h"
%}
%include "number.h"
%include "graph.h" // Graph declaration (inside the namespace gany)
using namespace gany;
%template(SGraph) Graph&lt;false&gt;; // Simple graph
// Note: the Graph name is redefined in the following line from the template to the specialization (class)
%template(WGraph) Graph&lt;true&gt;; // Weighted graph
%template(Number10) Number&lt;10&gt;;
%template(Number42) Number&lt;42&gt;;
</pre>
</div>

25
Doc/Manual/SWIG.html
View File

@ -3306,7 +3306,24 @@ Vector *new_Vector() {
</pre></div>
<p>
The <tt>%inline</tt> directive inserts all of the code that follows
This is the same as writing:
</p>
<div class="code"><pre>
%{
/* Create a new vector */
Vector *new_Vector() {
return (Vector *) malloc(sizeof(Vector));
}
%}
/* Create a new vector */
Vector *new_Vector() {
return (Vector *) malloc(sizeof(Vector));
}
</pre></div>
<p>
In other words, the <tt>%inline</tt> 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 <tt>new_Vector</tt> using only one
@ -3314,10 +3331,10 @@ declaration. Since the code inside an <tt>%inline %{ ... %}</tt> block
is given to both the C compiler and SWIG, it is illegal to include any
SWIG directives inside a <tt>%{ ... %}</tt> block.</p>
<p>
<b>Note:</b> Any <tt>#include</tt> directives are omitted inside the
<tt>%inline %{ ... %}</tt> block unless the <tt>-includeall</tt> command line
option is supplied.</p>
<b>Note:</b> The usual SWIG C preprocessor rules apply to code in <tt>%apply</tt> blocks when SWIG parses this code. For example, as mentioned earlier, <a href="SWIG.html#SWIG_nn6">SWIG's C Preprocessor</a> does not follow <tt>#include</tt> directives by default.
</p>
<H3><a name="SWIG_nn44">5.6.4 Initialization blocks</a></H3>