mirror of
https://github.com/boostorg/python.git
synced 2026-01-19 04:22:16 +00:00
96dd880146
https://svn.boost.org/svn/boost/trunk ........ r43206 | danieljames | 2008-02-10 09:55:03 +0000 (Sun, 10 Feb 2008) | 1 line Fix some broken links. ........ r43209 | danieljames | 2008-02-10 14:56:22 +0000 (Sun, 10 Feb 2008) | 1 line Link to people pages on the website, as they've been removed from the download. ........ r43210 | danieljames | 2008-02-10 15:02:17 +0000 (Sun, 10 Feb 2008) | 1 line Point links to the pages that used to be in 'more' to the site. ........ r43212 | danieljames | 2008-02-10 16:10:16 +0000 (Sun, 10 Feb 2008) | 1 line Fix links on the home page as well. ........ r43213 | danieljames | 2008-02-10 16:21:22 +0000 (Sun, 10 Feb 2008) | 1 line Generated documentation which is no longer generated. ........ [SVN r43214]
238 lines
10 KiB
HTML
238 lines
10 KiB
HTML
<!-- Copyright David Abrahams 2006. Distributed under the Boost -->
|
|
<!-- Software License, Version 1.0. (See accompanying -->
|
|
<!-- file LICENSE_1_0.txt or copy at http://www.boost.org/LICENSE_1_0.txt) -->
|
|
<html>
|
|
<head>
|
|
<meta http-equiv="Content-Type" content="text/html; charset=iso-8859-1">
|
|
<link rel="stylesheet" type="text/css" href="../boost.css">
|
|
<title>Boost.Python - March 2002 Progress Report</title>
|
|
</head>
|
|
<body link="#0000ff" vlink="#800080">
|
|
<table border="0" cellpadding="7" cellspacing="0" width="100%" summary=
|
|
"header">
|
|
<tr>
|
|
<td valign="top" width="300">
|
|
<h3><a href="../../../../index.htm"><img height="86" width="277" alt=
|
|
"C++ Boost" src="../../../../boost.png" border="0"></a></h3>
|
|
</td>
|
|
<td valign="top">
|
|
<h1 align="center"><a href="../index.html">Boost.Python</a></h1>
|
|
<h2 align="center">March 2002 Progress Report</h2>
|
|
</td>
|
|
</tr>
|
|
</table>
|
|
<hr>
|
|
<h2>Contents</h2>
|
|
<dl class="index">
|
|
<dt><a href="#accomplishments">Accomplishments</a></dt>
|
|
<dl class="index">
|
|
<dt><a href="#calling_python">Calling Python from C++</a></dt>
|
|
<dt><a href="#virtual_functions">Virtual Functions</a></dt>
|
|
<dt><a href="#abstract_classes">Abstract Classes</a></dt>
|
|
<dt><a href="#implicit_conversions">C++ Implicit Conversions</a></dt>
|
|
<dt><a href="#data_members">C++ Data Members</a></dt>
|
|
<dt><a href="#miscellaneous">Miscellaneous</a></dt>
|
|
</dl>
|
|
|
|
<dt><a href="#future">The Near future</a></dt>
|
|
|
|
<dt><a href="#notes">Notes</a></dt>
|
|
|
|
</dl>
|
|
|
|
<h2><a name="accomplishments">Accomplishments</a></h2>
|
|
|
|
March was mostly devoted to the reimplementation of features from
|
|
Boost.Python v1, and some new features. Re-examination of the features
|
|
from Boost.Python v1 allowed me to make significant improvements.
|
|
|
|
<h3><a name="calling_python">Calling Python from C++</a></h3>
|
|
|
|
The ability to call Python from C++ is crucial for virtual function
|
|
support. Implementing this feature well for V2 proved to be more
|
|
interesting than I expected. You can review most of the relevant
|
|
design decisions
|
|
<a href="callbacks.txt">here</a>.
|
|
|
|
<p>
|
|
One point which <i>isn't</i> emphasized in that document is that there
|
|
are subtle differences in the way <code>from_python</code> conversions
|
|
work when used for C++ function arguments and Python function return
|
|
values. In particular, while <code>T const&</code> arguments may
|
|
invoke rvalue converters, a reference-to-const return value requires
|
|
an lvalue converter, since a temporary conversion result would leave
|
|
the returned reference dangling.
|
|
|
|
<p>I'm not particularly pleased with the current callback interface,
|
|
since it usually results in constructs like:
|
|
<pre>
|
|
<u>return returning</u><X&>::call(f, obj);
|
|
</pre>
|
|
However, I think the following may be possible and I plan to investigate:
|
|
<pre>
|
|
return apply<X&>(f, obj);
|
|
</pre>
|
|
I'm open to suggestion for better names (and syntaxes)!
|
|
|
|
<h3><a name="virtual_functions">Virtual Functions</a></h3>
|
|
|
|
Once Python callbacks were implemented, it was just a short step to
|
|
implementing virtual functions. Python extension class exposing a C++
|
|
class whose virtual functions are overridable in Python must actually
|
|
hold a C++ instance of a class <i>derived</i> from the one exposed to
|
|
Python. Needing some way for users to specify that class, I added an
|
|
optional template argument to <code>value_holder_generator</code> and
|
|
<code>pointer_holder_generator<></code> to specify the class
|
|
actually held. This move began to put pressure on the
|
|
<code>class_<></code> interface, since the need for the user to
|
|
produce complicated instantations of
|
|
<code>class_<></code> was increased:
|
|
|
|
<pre>
|
|
class<Foo, bases<>, value_holder_generator<Foo_callback> >("Foo")
|
|
.def("hello", &Foo::hello)
|
|
...
|
|
</pre>
|
|
|
|
<h3><a name="abstract_classes">Abstract Classes</a></h3>
|
|
|
|
Normally when a C++ class is exposed to Python, the library registers
|
|
a conversion function which allows users to wrap functions returning
|
|
values of that type. Naturally, these return values are temporaries,
|
|
so the conversion function must make a copy in some
|
|
dynamically-allocated storage (a "holder") which is managed
|
|
by the corresponding Python object.
|
|
|
|
<p>Unfortunately, in the case of abstract classes (and other types
|
|
without a publicly-accessible copy constructor), instantiating this
|
|
conversion function causes a compilation error. In order to support
|
|
non-copyable classes, there had to be some way to prevent the library
|
|
from trying to instantiate the conversion function. The only practical
|
|
approach I could think of was to add an additional template parameter
|
|
to the <code>class_<></code> interface. When the number of
|
|
template parameters with useful defaults begins to grow, it is often
|
|
hard to choose an order which allows users to take advantage of the
|
|
defaults.
|
|
|
|
<p>
|
|
|
|
This was the straw that broke the
|
|
<code>class_<></code> interface's back and caused the redesign
|
|
whose outcome is detailed <a
|
|
href="http://mail.python.org/pipermail/c++-sig/2002-March/000892.html">here</a>.
|
|
The approach allows the user to supply the optional parameters in an
|
|
arbitrary order. It was inspired by the use of <a
|
|
href="../../../utility/iterator_adaptors.htm#named_tempalte_parameters">named
|
|
template parameters</a> in the <a
|
|
href="../../../utility/iterator_adaptors.htm">Boost Iterator Adaptor
|
|
Library</a>, though in this case it is possible to deduce the meaning
|
|
of the template parameters entirely from their type properties,
|
|
resulting in a simpler interface. Although the move from a
|
|
policy-based design to what resembles a configuration DSL usually
|
|
implies a loss of flexibility, in this case I think any costs are far
|
|
outweighed by the advantages.
|
|
|
|
<p>Note: working around the limitations of the various compilers I'm
|
|
supporting was non-trivial, and resulted in a few messy implementation
|
|
details. It might be a good idea to switch to a more-straightforward
|
|
approach once Metrowerks CodeWarrior Pro8 is released.
|
|
|
|
<h3><a name="implicit_conversions">C++ Implicit Conversions</a></h3>
|
|
|
|
Support for C++ implicit conversion involves creating
|
|
<code>from_python</code> converters for a type <code>U</code> which in
|
|
turn use <code>from_python</code> converters registered for a type
|
|
<code>T</code> where there exists a implicit conversion from
|
|
<code>T</code> to <code>U</code>. The current implementation is
|
|
subject to two inefficiencies:
|
|
<ol>
|
|
|
|
<li>Because an rvalue <code>from_python</code> converter produces two
|
|
pieces of data (a function and a <code>void*</code>) from its
|
|
<code>convertible()</code> function, we end up calling the function
|
|
for <code>T</code> twice: once when the converter is looked up in the
|
|
registry, and again when the conversion is actually performed.
|
|
|
|
<li>A vector is used to mark the "visited" converters, preventing
|
|
infinite recursion as <code>T</code> to
|
|
<code>U</code> and <code>U</code> to <code>T</code> converters
|
|
continually search through one-another.
|
|
|
|
</ol>
|
|
|
|
I consider the former to be a minor issue. The second may or may not
|
|
prove to be computationally significant, but I believe that
|
|
architecturally, it points toward a need for more sophisticated
|
|
overload resolution. It may be that we want CLOS-style multimethod
|
|
dispatching along with C++ style rules that prevent more than one
|
|
implicit conversion per argument.
|
|
|
|
<h3><a name="data_members">C++ Data Members</a></h3>
|
|
|
|
To supply the ability to directly access data members, I was able to
|
|
hijack the new Python <a
|
|
href="http://www.python.org/2.2/descrintro.html#property">property</a>
|
|
type. I had hoped that I would also be able to re-use the work of <a
|
|
href="make_function.html">make_function</a> to create callable python
|
|
objects from C++ functions which access a data member of a given
|
|
class. C++ facilities for specifying data member pointer non-type
|
|
template arguments require the user to explicitly specify the type of
|
|
the data member and this under-utilized feature is also not
|
|
well-implemented on all compilers, so passing the member pointer as a
|
|
runtime value is the only practical approach. The upshot is that any
|
|
such entity would actually have to be a function <i>object</i>, and I
|
|
haven't implemented automatic wrapping of C++ callable function
|
|
objects yet, so there is less re-use in the implementation than I'd
|
|
like. I hope to implement callable object wrapping and refactor this
|
|
code one day. I also hope to implement static data member support,
|
|
for which Python's property will not be an appropriate descriptor.
|
|
|
|
<h3><a name="miscellaneous">Miscellaneous</a></h3>
|
|
<ul>
|
|
<li>Moved <code>args<></code> and <code>bases<></code> from unnamed namespace to <code>boost::python</code> in their own header files.
|
|
<li>Convert <code>NULL</code> pointers returned from wrapped C++ functions to <code>None</code>.
|
|
<li>Improved some compile-time error checks.
|
|
<li>Eliminated <code>boost/python/detail/eval.hpp</code> in favor of
|
|
more-general <code>boost/mpl/apply.hpp</code>.
|
|
<li>General code cleanup and refactoring.
|
|
<li>Works with Microsoft Visual C++ 7.0
|
|
<li>Warning suppression for many compilers
|
|
<li>Elegant interface design for exporting <code>enum</code> types.
|
|
</ul>
|
|
<hr>
|
|
|
|
<h2><a name="future">The Near Future</a></h2>
|
|
|
|
Before April 15th I plan to
|
|
<ol>
|
|
<li>Document all implemented features
|
|
<li>Implement a <code>CallPolicy</code> interface for constructors of wrapped
|
|
classes
|
|
<li>Implement conversions for <code>char</code> types.
|
|
<li>Implement automated code generation for all headers containing
|
|
families of overloaded functions to handle arbitrary arity.
|
|
</ol>
|
|
|
|
I also hope to implement a mechanism for generating conversions
|
|
between arbitrary Python sequences and C++ containers, if time permits
|
|
(and others haven't already done it)!
|
|
|
|
<h2><a name="notes">Notes</a></h2>
|
|
|
|
The older version of KCC used by Kull is generating lots of warnings
|
|
about a construct I use to instantiate static members of various class
|
|
templates. I'm thinking of moving to an idiom which uses a function
|
|
template to suppress it, but worry about bloating the size of debug
|
|
builds. Since KCC users may be moving to GCC, I'm not sure that it's
|
|
worth doing anything about it.
|
|
|
|
<p>Revised
|
|
<!--webbot bot="Timestamp" S-Type="EDITED" S-Format="%d %B, %Y" startspan -->
|
|
13 November, 2002
|
|
<!--webbot bot="Timestamp" endspan i-checksum="39359" -->
|
|
</p>
|
|
<p><i>© Copyright <a href="http://www.boost.org/people/dave_abrahams.htm">Dave Abrahams</a>
|
|
2002. </i></p>
|
|
</body>
|
|
</html>
|