Remove pointer.i from the SWIG library

It's been a dummy file which has done nothing except %echo a deprecation
message since 2002.  The replacement is cpointer.i.
This commit is contained in:
Olly Betts 2023-06-15 15:50:51 +12:00
parent 8ad0b79740
commit c916d81e8d
9 changed files with 59 additions and 80 deletions

View File

@ -7,6 +7,11 @@ the issue number to the end of the URL: https://github.com/swig/swig/issues/
Version 4.2.0 (in progress)
===========================
2023-06-15: olly
Remove pointer.i from the SWIG library. It's been a dummy file
which has done nothing except %echo a deprecation message since
2002. The replacement is cpointer.i.
2023-06-15: olly
SWIG will no longer fall back to using the include path to find the
input file, which has been deprecated and emitted a warning since

View File

@ -48,7 +48,7 @@ like this:
<div class="code">
<pre>
%include "pointer.i"
%include "cpointer.i"
</pre>
</div>

View File

@ -72,23 +72,25 @@ you would do this:
<blockquote>
<pre>
%include "pointer.i"
%include "cpointer.i"
</pre>
</blockquote?
</blockquote>
and in a script you would do this:
<blockquote>
<pre>
$a = ptrcreate("int",37);
$b = ptrcreate("int",42);
$c = ptrcreate("int");
add($a,$b,$c);
$r = ptrvalue($c);
$a = example::new_intp();
$b = example::new_intp();
$c = example::new_intp();
example::intp_assign($a,37);
example::intp_assign($b,42);
example::add($a,$b,$c);
$r = example::intp_value($c);
print "Result = $r\n";
ptrfree($a);
ptrfree($b);
ptrfree($c);
example::delete_intp($a);
example::delete_intp($b);
example::delete_intp($c);
</pre>
</blockquote>
@ -156,14 +158,8 @@ etc...) the complexity of pointer handling can be as complicated as you want to
make it.
<p>
<li>More documentation on the typemaps.i and pointer.i library files can be
<li>More documentation on the typemaps.i and cpointer.i library files can be
found in the SWIG user manual. The files also contain documentation.
<p>
<li>The pointer.i library is designed primarily for convenience. If you
are concerned about performance, you probably want to use a different
approach.
</ul>
<hr>

View File

@ -72,23 +72,25 @@ you would do this:
<blockquote>
<pre>
%include "pointer.i"
%include "cpointer.i"
</pre>
</blockquote?
</blockquote>
and in a script you would do this:
<blockquote>
<pre>
a = ptrcreate("int",37)
b = ptrcreate("int",42)
c = ptrcreate("int")
add(a,b,c)
r = ptrvalue(c)
print "Result =",r
ptrfree(a)
ptrfree(b)
ptrfree(c)
a = example.new_intp()
b = example.new_intp()
c = example.new_intp()
example.intp_assign(a, 37)
example.intp_assign(b, 42)
example.add(a, b, c)
r = example.intp_value(c)
print("Result = %s" % r)
example.delete_intp(a)
example.delete_intp(b)
example.delete_intp(c)
</pre>
</blockquote>
@ -156,14 +158,9 @@ etc...) the complexity of pointer handling can be as complicated as you want to
make it.
<p>
<li>More documentation on the typemaps.i and pointer.i library files can be
<li>More documentation on the typemaps.i and cpointer.i library files can be
found in the SWIG user manual. The files also contain documentation.
<p>
<li>The pointer.i library is designed primarily for convenience. If you
are concerned about performance, you probably want to use a different
approach.
</ul>
<hr>

View File

@ -54,15 +54,17 @@ Now, in a script you would do this:
<blockquote>
<pre>
a = new_int(37)
b = new_int(42)
c = new_int(0)
add(a,b,c)
r = get_int(c)
a = Example::new_intp()
b = Example::new_intp()
c = Example::new_intp()
Example::intp_assign(a,37)
Example::intp_assign(b,42)
Example::add(a, b, c)
r = Example::intp_value(c)
print "Result = #{r}\n"
delete_int(a)
delete_int(b)
delete_int(c)
Example::delete_intp(a)
Example::delete_intp(b)
Example::delete_intp(c)
</pre>
</blockquote>
@ -72,7 +74,7 @@ you would do this:
<blockquote>
<pre>
%include "pointer.i"
%include "cpointer.i"
</pre>
</blockquote>
@ -156,14 +158,8 @@ etc...) the complexity of pointer handling can be as complicated as you want to
make it.
<p>
<li>More documentation on the typemaps.i and pointer.i library files can be
<li>More documentation on the typemaps.i and cpointer.i library files can be
found in the SWIG user manual. The files also contain documentation.
<p>
<li>The pointer.i library is designed primarily for convenience. If you
are concerned about performance, you probably want to use a different
approach.
</ul>
<hr>

View File

@ -72,23 +72,25 @@ you would do this:
<blockquote>
<pre>
%include "pointer.i"
%include "cpointer.i"
</pre>
</blockquote?
</blockquote>
and in a script you would do this:
<blockquote>
<pre>
set a [ptrcreate int 37]
set b [ptrcreate int 42]
set c [ptrcreate int]
set a [new_intp]
set b [new_intp]
set c [new_intp]
intp_assign $a 37
intp_assign $b 42
add $a $b $c
set r [ptrvalue $c]
set r [intp_value $c]
puts "Result = $r"
ptrfree $a
ptrfree $b
ptrfree $c
delete_intp $a
delete_intp $b
delete_intp $c
</pre>
</blockquote>
@ -156,14 +158,8 @@ etc...) the complexity of pointer handling can be as complicated as you want to
make it.
<p>
<li>More documentation on the typemaps.i and pointer.i library files can be
<li>More documentation on the typemaps.i and cpointer.i library files can be
found in the SWIG user manual. The files also contain documentation.
<p>
<li>The pointer.i library is designed primarily for convenience. If you
are concerned about performance, you probably want to use a different
approach.
</ul>
<hr>

View File

@ -6,7 +6,7 @@
/* First we'll use the pointer library */
extern void add(int *x, int *y, int *result);
%include pointer.i
%include cpointer.i
/* Next we'll use some typemaps */

View File

@ -14,7 +14,7 @@ void enum_test(color c, Foo::speed s);
%include pointer.i
%include cpointer.i
/* Next we'll use some typemaps */

View File

@ -1,11 +0,0 @@
/* -----------------------------------------------------------------------------
* pointer.i
* ----------------------------------------------------------------------------- */
%echo "pointer.i is deprecated. Use cpointer.i instead."
%echo "See https://www.swig.org/Doc3.0/Library.html"