boost/python
2
0
Fork 0
mirror of https://github.com/boostorg/python.git synced 2026-01-23 17:52:17 +00:00
Code Issues Projects Releases Wiki Activity

This commit was manufactured by cvs2svn to create tag

Browse Source 
'Version_1_21_2'.

[SVN r9983]
This commit is contained in:
nobody
2001-04-25 14:10:57 +00:00
parent 9b602d16b4
commit 718adad485
95 changed files with 8389 additions and 923 deletions
Download Patch File Download Diff File Expand all files Collapse all files

27
doc/pointers.html
View File

@@ -13,7 +13,7 @@
<p>
In general, raw pointers passed to or returned from functions are problematic
for py_cpp because pointers have too many potential meanings. Is it an iterator?
for Boost.Python because pointers have too many potential meanings. Is it an iterator?
A pointer to a single element? An array? When used as a return value, is the
caller expected to manage (delete) the pointed-to object or is the pointer
really just a reference? If the latter, what happens to Python references to the
@@ -34,12 +34,10 @@ converted from/to Python strings.
<h3>Can you avoid the problem?</h3>
<p>My first piece of advice to anyone with a case not covered above is
&ldquo;find a way to avoid the problem.&rdquo; For example, if you have just one
or two functions returning a pointer to a single (not an array of) <code>const
T*</code> for some wrapped <code>T</code>, you may be able to write a &ldquo;thin
converting wrapper&rdquo; over those two functions as follows (Since py_cpp
converts <code>const T&</code> values <code>to_python</code> by copying the T
into a new extension instance, Foo must have a public copy constructor):
``find a way to avoid the problem.'' For example, if you have just one
or two functions that return a pointer to an individual <code>const
T</code>, and <code>T</code> is a wrapped class, you may be able to write a ``thin
converting wrapper'' over those two functions as follows:
<blockquote><pre>
const Foo* f(); // original function
@@ -47,6 +45,10 @@ const Foo& f_wrapper() { return *f(); }
...
my_module.def(f_wrapper, "f");
</pre></blockquote>
<p>
Foo must have a public copy constructor for this technique to work, since Boost.Python
converts <code>const T&</code> values <code>to_python</code> by copying the <code>T</code>
value into a new extension instance.
<h2>Dealing with the problem</h2>
@@ -83,12 +85,12 @@ code before the last Python reference to it disappears:
BOOST_PYTHON_BEGIN_CONVERSION_NAMESPACE // this is a gcc 2.95.2 bug workaround
PyObject* to_python(Foo* p)
{
return boost::python::PyExtensionClassConverters<Foo>::ptr_to_python(p);
return boost::python::python_extension_class_converters&ltFoo&gt::ptr_to_python(p);
}
PyObject* to_python(const Foo* p)
{
return to_python(const_cast<Foo*>(p));
return to_python(const_cast&lt;Foo*&gt;(p));
}
BOOST_PYTHON_END_CONVERSION_NAMESPACE
</pre></blockquote>
@@ -118,7 +120,7 @@ return value. You can handle this case by returning a Python tuple:
typedef unsigned ErrorCode;
const char* f(int* in_out_x); // original function
...
#include <boost/python/objects.hpp>
#include &lt;boost/python/objects.hpp&gt;
const boost::python::tuple f_wrapper(int in_x) {
const char* s = f(in_x);
return boost::python::tuple(s, in_x);
@@ -131,8 +133,9 @@ my_module.def(f_wrapper, "f");
&gt;&gt;&gt; str,out_x = f(3)
</pre></blockquote>
<p>
Previous: <a href="enums.html">Enums</a>
Up: <a href="index.html">Top</a>
<p>
&copy; Copyright David Abrahams 2000. Permission to copy, use, modify,
sell and distribute this document is granted provided this copyright