jyapayne/swig
1
0
Fork 0
Code Issues Pull requests Projects Releases Packages Wiki Activity Actions

Fix typos

Browse source
This commit is contained in:
Dimitris Apostolou 2022-02-09 11:12:46 +02:00 • committed by Olly Betts
commit 40c3bf30b2
10 changed files with 13 additions and 13 deletions
Download patch file Download diff file Expand all files Collapse all files

2
Doc/Manual/Extending.html
View file

@ -2991,7 +2991,7 @@ virtual int functionWrapper(Node *n) {
/* create the wrapper object */
Wrapper *wrapper = NewWrapper();
/* create the functions wrappered name */
/* create the functions wrapped name */
String *wname = Swig_name_wrapper(iname);
/* deal with overloading */

2
Doc/Manual/Library.html
View file

@ -2136,7 +2136,7 @@ struct A {
<p>
and you want to provide that variable as an attribute in the target
langage. This example only works for primitive types, not derived
language. This example only works for primitive types, not derived
types.
Now you can use the attributes like so (in Python):
</p>

2
Doc/Manual/Php.html
View file

@ -375,7 +375,7 @@ then the default "compat" setting should work well.
</p>
<p>
If you're writing a new set of bindings and <b>only targetting PHP8 or newer</b>
If you're writing a new set of bindings and <b>only targeting PHP8 or newer</b>
then enabling type declarations everywhere probably makes sense. It will
only actually make a difference if you enable directors and are wrapping C++
classes with virtual methods, but doing it anyway means you won't forget to if

4
Doc/Manual/Scilab.html
View file

@ -768,7 +768,7 @@ Pointers are supported by SWIG. A pointer can be returned from a wrapped C/C++ f
Also, thanks to the SWIG runtime which stores information about types, pointer types are tracked between exchanges Scilab and the native code. Indeed pointer types are stored alongside the pointer address.
A pointer is mapped to a Scilab structure (<a href="https://help.scilab.org/docs/5.5.2/en_US/tlist.html">tlist</a>), which contains as fields the pointer address and the pointer type (in fact a pointer to the type information structure in the SWIG runtime).
<br>
Why a native pointer is not mapped to a Scilab pointer (type name: "pointer", type ID: 128) ? The big advantage of mapping to a <tt>tlist</tt> is that it exposes a new type for the pointer in Scilab, type which can be acessed in Scilab with the <a href="https://help.scilab.org/docs/5.5.2/en_US/typeof.html">typeof</a> function, and manipulated using the <a href="https://help.scilab.org/docs/5.5.2/en_US/overloading.html">overloading</a> mechanism.
Why a native pointer is not mapped to a Scilab pointer (type name: "pointer", type ID: 128) ? The big advantage of mapping to a <tt>tlist</tt> is that it exposes a new type for the pointer in Scilab, type which can be accessed in Scilab with the <a href="https://help.scilab.org/docs/5.5.2/en_US/typeof.html">typeof</a> function, and manipulated using the <a href="https://help.scilab.org/docs/5.5.2/en_US/overloading.html">overloading</a> mechanism.
</p>
<p>
@ -776,7 +776,7 @@ Notes:
</p>
<ul>
<li>type tracking needs the SWIG runtime to be first initialized with the appropriate function (see the <a href="#Scilab_module_initialization">Module initialization</a> section).</li>
<li>for any reason, if a wrapped pointer type is unknown (or if the SWIG runtime is not initialized), SWIG maps it to a Scilab pointer. Also, a Scilab pointer is always accepted as a pointer argument of a wrapped function. The drawaback is that pointer type is lost.</li>
<li>for any reason, if a wrapped pointer type is unknown (or if the SWIG runtime is not initialized), SWIG maps it to a Scilab pointer. Also, a Scilab pointer is always accepted as a pointer argument of a wrapped function. The drawback is that pointer type is lost.</li>
</ul>
<p>