用Boost.Python构建混合系统

川长思鸟来 2022-08-02 01:29 197阅读 0赞

# [Building Hybrid Systems with Boost.Python][] #

# 用Boost.Python构建混合系统 #

<table>       
 <tbody> 
  <tr> 
   <th>Author:</th> 
   <td>David Abrahams</td> 
  </tr> 
  <tr> 
   <th>Contact:</th> 
   <td><a href="mailto:dave@boost-consulting.com" rel="nofollow"><span style="COLOR: #000080; FONT-FAMILY: ">dave@boost-consulting.com</span></a></td> 
  </tr> 
  <tr> 
   <th>Organization:</th> 
   <td><a href="http://www.boost-consulting.com/" rel="nofollow"><span style="COLOR: #000080; FONT-FAMILY: ">Boost Consulting</span></a></td> 
  </tr> 
  <tr> 
   <th>Date:</th> 
   <td>2003-03-19</td> 
  </tr> 
  <tr> 
   <th>Author:</th> 
   <td>Ralf W. Grosse-Kunstleve</td> 
  </tr> 
  <tr> 
   <th>Copyright:</th> 
   <td>Copyright David Abrahams and Ralf W. Grosse-Kunstleve 2003. All rights reserved</td> 
  </tr> 
  <tr> 
   <th>翻译:</th> 
   <td> <p><a href="http://jerrywang-cn.spaces.live.com/blog/cns!7762C01175E3FC8!196.entry" rel="nofollow"><span style="COLOR: #000080; FONT-FAMILY: ">王志勇</span></a>，<a href="http://my.donews.com/slowness/2006/04/09" rel="nofollow"><span style="COLOR: #000080; FONT-FAMILY: ">Slowness Chen</span></a>，<a href="http://blog.csdn.net/jq0123" rel="nofollow"><span style="COLOR: #000080; FONT-FAMILY: ">金庆</span></a></p> <p><a href="http://www.cppblog.com/jinq0123/archive/2008/05/29/BuildingHybridSystemswithBoostPython_c.html" rel="nofollow">http://www.cppblog.com/jinq0123/archive/2008/05/29/BuildingHybridSystemswithBoostPython_c.html</a></p> </td> 
  </tr> 
  <tr> 
   <th>译文更新:</th> 
   <td>2008-05-29</td> 
  </tr> 
 </tbody> 
</table>

Table of Contents

*  [Abstract][]
 *  [Introduction][]
 *  [Boost.Python Design Goals][]
 *  [Hello Boost.Python World][]
 *  [Library Overview][]
    
     *  [Exposing Classes][]
        
         *  [Constructors][]
         *  [Data Members and Properties][]
         *  [Operator Overloading][]
         *  [Inheritance][]
         *  [Virtual Functions][]
         *  [Deeper Reflection on the Horizon?][Deeper Reflection on the Horizon]
     *  [Serialization][]
     *  [Object interface][]
 *  [Thinking hybrid][]
 *  [Development history][]
 *  [Conclusions][]
 *  [Citations][]
 *  [Footnotes][]

*  [摘要][Abstract]
 *  [介绍][Introduction]
 *  [Boost.Python的设计目标][Boost.Python Design Goals]
 *  [Hello Boost.Python World][]
 *  [库概览][Library Overview]
    
     *  [导出类][Exposing Classes]
        
         *  [构造函数][Constructors]
         *  [数据成员和属性][Data Members and Properties]
         *  [运算符重载][Operator Overloading]
         *  [继承][Inheritance]
         *  [虚函数][Virtual Functions]
         *  [更深的反射即将出现？][Deeper Reflection on the Horizon]
     *  [序列化][Serialization]
     *  [Object接口][Object interface]
 *  [混合地思考][Thinking hybrid]
 *  [开发历史][Development history]
 *  [结论][Conclusions]
 *  [引用][Citations]
 *  [脚注][Footnotes]

# [Abstract][Abstract 1] #

# 摘要 #

Boost.Python is an open source C++ library which provides a conciseIDL-like interface for binding C++ classes and functions toPython. Leveraging the full power of C++ compile-time introspectionand of recently developed metaprogramming techniques, this is achievedentirely in pure C++, without introducing a new syntax.Boost.Python's rich set of features and high-level interface make itpossible to engineer packages from the ground up as hybrid systems,giving programmers easy and coherent access to both the efficientcompile-time polymorphism of C++ and the extremely convenient run-timepolymorphism of Python.

Boost.Python是一个开源C++库，它提供了一个简明的IDL式的接口，用于把C++类和函数绑定到Python。借助C++强大的编译时内省能力和最近发展的元编程技术，绑定工作完全用纯C++实现，而没有引入新的语法。Boost.Python丰富的特性和高级接口，使得完全按混合系统设计软件包成为可能，并让程序员以轻松连贯的方式，同时使用C++高效的编译时多态，和Python极端便利的运行时多态。

# [Introduction][Introduction 1] #

# 介绍 #

Python and C++ are in many ways as different as two languages couldbe: while C++ is usually compiled to machine-code, Python isinterpreted.  Python's dynamic type system is often cited as thefoundation of its flexibility, while in C++ static typing is thecornerstone of its efficiency. C++ has an intricate and difficultcompile-time meta-language, while in Python, practically everythinghappens at runtime.

作为两种语言，Python和C++存在很多差异。C++一般被编译为机器码，而Python是解释执行的。Python的动态类型系统通常被认为是它灵活性的基础，而C++的静态类型系统是C++效率的基石。C++有一种复杂艰深的编译时元语言，而在Python中，几乎一切都发生在运行时。

Yet for many programmers, these very differences mean that Python andC++ complement one another perfectly.  Performance bottlenecks inPython programs can be rewritten in C++ for maximal speed, andauthors of powerful C++ libraries choose Python as a middlewarelanguage for its flexible system integration capabilities.Furthermore, the surface differences mask some strong similarities:

然而对很多程序员来说，这些差异也意味着Python和C++可以完美互补。为了提高运行速度，Python程序的性能瓶颈可以用C++重写，而大型C++库的作者们，为了获得灵活的系统集成能力，选择Python作为中间件语言。此外，在表面差异掩盖之下，二者有一些非常相似之处：

*  'C'-family control structures (if, while, for...)
 *  Support for object-orientation, functional programming, and genericprogramming (these are both *multi-paradigm* programming languages.)
 *  Comprehensive operator overloading facilities, recognizing theimportance of syntactic variability for readability andexpressivity.
 *  High-level concepts such as collections and iterators.
 *  High-level encapsulation facilities (C++: namespaces, Python: modules)to support the design of re-usable libraries.
 *  Exception-handling for effective management of error conditions.
 *  C++ idioms in common use, such as handle/body classes andreference-counted smart pointers mirror Python reference semantics.

*  'C'-家族的控制结构（if, while, for...）
 *  支持面向对象、函数式编程，以及泛型编程（它们都是*多范式（multi-paradigm）*编程语言。）
 *  认同语法可变性（syntactic variability）对于提高代码可读性和表达力的重要作用，提供了对运算符重载的广泛支持。
 *  高级概念，如集合和迭代器。
 *  高级封装机制（C++：名字空间，Python：模块），以支持可重用库的设计。
 *  异常处理，提供有效的错误管理。
 *  通用的C++惯用法，如handle/body类，和引用计数的智能指针，即Python的引用语义。

Given Python's rich 'C' interoperability API, it should in principlebe possible to expose C++ type and function interfaces to Python withan analogous interface to their C++ counterparts.  However, thefacilities provided by Python alone for integration with C++ arerelatively meager.  Compared to C++ and Python, 'C' has only veryrudimentary abstraction facilities, and support for exception-handlingis completely missing.  'C' extension module writers are required tomanually manage Python reference counts, which is both annoyinglytedious and extremely error-prone. Traditional extension modules alsotend to contain a great deal of boilerplate code repetition whichmakes them difficult to maintain, especially when wrapping an evolvingAPI.

因为Python有着丰富的'C'语言集成API，原则上，向Python导出C++类型和函数接口应该是可行的，并且导出的接口与对应C++的接口应该是相似的。然而，Python本身提供的C++集成功能相对比较弱。和C++，Python相比，'C'只有非常基本的抽象能力，而且完全不支持异常处理。'C'扩展模块的作者必须手工管理Python的引用计数，这不仅单调乏味，令人恼火，而且还极易出错。传统的扩展模块往往包含大量重复的样板代码，使它们难以维护，尤其是当要封装的API尚处于发展之中。

These limitations have lead to the development of a variety of wrappingsystems.  [SWIG][] is probably the most popular package for theintegration of C/C++ and Python. A more recent development is [SIP][],which was specifically designed for interfacing Python with the [Qt][]graphical user interface library.  Both SWIG and SIP introduce theirown specialized languages for customizing inter-language bindings.This has certain advantages, but having to deal with three differentlanguages (Python, C/C++ and the interface language) also introducespractical and mental difficulties.  The [CXX][] package demonstrates aninteresting alternative.  It shows that at least some parts ofPython's 'C' API can be wrapped and presented through a much moreuser-friendly C++ interface. However, unlike SWIG and SIP, CXX doesnot include support for wrapping C++ classes as new Python types.

这些限制导致了多种封装系统的发展。[SWIG][]可能是最流行的C/C++和Python集成系统。还有最近发展的[SIP][]，它是专门为[Qt][]图形用户界面库设计的，用于提供Qt的Python接口。为了定制语言间的绑定，SWIG和SIP都引入了它们自己的专用语言。这有一定的好处，但是你不得不去应付三种不同语言（Python、C/C++和接口语言），所以也带来了事实上和心理上的困难。[CXX][]软件包展示了另一种令人感兴趣的选择。它显示，至少可以封装部分Python 'C' API，将它们表示为更友好的C++接口。然而，不像SWIG和SIP，CXX不能将C++类封装成新的Python类型。

The features and goals of [Boost.Python][] overlap significantly withmany of these other systems.  That said, Boost.Python attempts tomaximize convenience and flexibility without introducing a separatewrapping language.  Instead, it presents the user with a high-levelC++ interface for wrapping C++ classes and functions, managing much ofthe complexity behind-the-scenes with static metaprogramming.Boost.Python also goes beyond the scope of earlier systems byproviding:

[Boost.Python][]的特性和目标与这些系统有很多重叠。Boost.Python努力提高封装的便利性和灵活性，但不引入单独的封装语言。相反，它通过静态元编程，在幕后管理大量的复杂性，呈现给用户一个高级C++接口来封装C++类和函数。Boost.Python也在如下领域超越了早期的系统：

*  Support for C++ virtual functions that can be overridden in Python.
 *  Comprehensive lifetime management facilities for low-level C++pointers and references.
 *  Support for organizing extensions as Python packages,with a central registry for inter-language type conversions.
 *  A safe and convenient mechanism for tying into Python's powerfulserialization engine (pickle).
 *  Coherence with the rules for handling C++ lvalues and rvalues thatcan only come from a deep understanding of both the Python and C++type systems.

*  支持C++虚函数，并能在Python中覆盖。
 *  对于低级的C++指针和引用，提供全面的生命期管理机制。
 *  支持按Python包组织扩展模块，通过中心注册表进行语言间类型转换。
 *  通过一种安全方便的机制，引入Python强大的序列化引擎（pickle）。
 *  与C++处理左值和右值的规则相一致，该一致性只能来自于对Python和C++类型系统的深入理解。

The key insight that sparked the development of Boost.Python is thatmuch of the boilerplate code in traditional extension modules could beeliminated using C++ compile-time introspection.  Each argument of awrapped C++ function must be extracted from a Python object using aprocedure that depends on the argument type.  Similarly the function'sreturn type determines how the return value will be converted from C++to Python.  Of course argument and return types are part of eachfunction's type, and this is exactly the source from whichBoost.Python deduces most of the information required.

一个关键性的发现启动了Boost.Python的开发，即利用C++的编译时内省，可以消除传统扩展模块中的大量样板代码。如每个封装的C++函数的参数都是从Python对象提取的，提取时必须根据参数类型调用相应的过程。类似地，函数返回值从C++转换成Python时，返回值的类型决定了如何转换。因为参数和返回值的类型是每个函数类型的一部分，所以Boost.Python可以从函数类型推导出大部分所需的信息。

This approach leads to *user guided wrapping*: as much information isextracted directly from the source code to be wrapped as is possiblewithin the framework of pure C++, and some additional information issupplied explicitly by the user.  Mostly the guidance is mechanicaland little real intervention is required.  Because the interfacespecification is written in the same full-featured language as thecode being exposed, the user has unprecedented power available whenshe does need to take control.

这种方法导致了“*用户指导的封装（user guided wrapping）*”：在纯C++的框架内，从待封装的源代码中直接提取尽可能多的信息，而一些额外的信息由用户显式提供。通常这种指导是自动的，很少需要真正的干涉。因为接口规范和导出代码是用同一门全功能的语言写的，当用户确实需要取得控制时，他所拥有的权力是空前强大的。

# [Boost.Python Design Goals][Boost.Python Design Goals 1] #

# Boost.Python的设计目标 #

The primary goal of Boost.Python is to allow users to expose C++classes and functions to Python using nothing more than a C++compiler.  In broad strokes, the user experience should be one ofdirectly manipulating C++ objects from Python.

Boost.Python的首要目标是，让用户只用C++编译器就能向Python导出C++类和函数。大体来讲，用户的体验应该是，能够从Python直接操作C++对象。

However, it's also important not to translate all interfaces *too*literally: the idioms of each language must be respected.  Forexample, though C++ and Python both have an iterator concept, they areexpressed very differently.  Boost.Python has to be able to bridge theinterface gap.

然而，有一点也很重要，那就是不要*过于*按字面翻译所有接口：必须考虑每种语言的惯用法。例如，虽然C++和Python都有迭代器的概念，表达方式却很不一样。Boost.Python必须能够消除这种接口的差异。

It must be possible to insulate Python users from crashes resultingfrom trivial misuses of C++ interfaces, such as accessingalready-deleted objects.  By the same token the library shouldinsulate C++ users from low-level Python 'C' API, replacingerror-prone 'C' interfaces like manual reference-count management andraw PyObject pointers with more-robust alternatives.

Python用户可能会误用C++接口，因此，Boost.Python必须能够隔离因轻微的误用而造成的崩溃，例如访问已删除的对象。同样的，Boost.Python库应该把C++用户从低级的Python 'C' API中解放出来，将容易出错的'C'接口，如手工引用计数管理、原始的PyObject指针，替换为更健壮的接口。

Support for component-based development is crucial, so that C++ typesexposed in one extension module can be passed to functions exposed inanother without loss of crucial information like C++ inheritancerelationships.

支持基于组件的开发是至关重要的，这样，一个扩展模块导出的C++类型，可以传递给另一个模块导出的函数，而不丢失重要的信息，比如C++的继承关系。

Finally, all wrapping must be *non-intrusive*, without modifying oreven seeing the original C++ source code.  Existing C++ libraries haveto be wrappable by third parties who only have access to header filesand binaries.

最后，所有的封装必须是*非侵入性的（non-intrusive）*，不能修改最初的C++源码，甚至不必看到源码。第三方必须能够封装现有的C++库，即使他只有头文件和二进制库。

# [Hello Boost.Python World][Hello Boost.Python World 1] #

# Hello Boost.Python World #

And now for a preview of Boost.Python, and how it improves on the rawfacilities offered by Python. Here's a function we might want toexpose:

现在来预览一下Boost.Python，看看它是如何改进Python原有的封装机制的。下面是我们想导出的函数:

char const* greet(unsigned x)
    {
        
       static char const* const msgs[] = { "hello", "Boost.Python", "world!" };
    
       if (x > 2) 
           throw std::range_error("greet: index out of range");
    
       return msgs[x];
    }

To wrap this function in standard C++ using the Python 'C' API, we'dneed something like this:

在标准C++中，用Python 'C' API来封装这个函数，我们需要像这样做:

extern "C" // all Python interactions use 'C' linkage and calling convention
    {
        
        // Wrapper to handle argument/result conversion and checking
        PyObject* greet_wrap(PyObject* args, PyObject * keywords)
        {
        
             int x;
             if (PyArg_ParseTuple(args, "i", &x))    // extract/check arguments
             {
        
                 char const* result = greet(x);      // invoke wrapped function
                 return PyString_FromString(result); // convert result to Python
             }
             return 0;                               // error occurred
        }
    
        // Table of wrapped functions to be exposed by the module
        static PyMethodDef methods[] = {
        
            { "greet", greet_wrap, METH_VARARGS, "return one of 3 parts of a greeting" }
            , { NULL, NULL, 0, NULL } // sentinel
        };
    
        // module initialization function
        DL_EXPORT init_hello()
        {
        
            (void) Py_InitModule("hello", methods); // add the methods to the module
        }
    }

Now here's the wrapping code we'd use to expose it with Boost.Python:

而这是用Boost.Python来导出函数的封装代码：

#include <boost/python.hpp>
    using namespace boost::python;
    BOOST_PYTHON_MODULE(hello)
    {
        
        def("greet", greet, "return one of 3 parts of a greeting");
    }

and here it is in action:

这是运行结果：

>>> import hello
    >>> for x in range(3):
    ...     print hello.greet(x)
    ...
    hello
    Boost.Python
    world!

Aside from the fact that the 'C' API version is much more verbose,it's worth noting a few things that it doesn't handle correctly:

使用'C' API的版本要冗长的多，此外，还需要注意，有些东西它没有正确处理：

*  The original function accepts an unsigned integer, and the Python'C' API only gives us a way of extracting signed integers. TheBoost.Python version will raise a Python exception if we try to passa negative number to hello.greet, but the other one will proceedto do whatever the C++ implementation does when converting annegative integer to unsigned (usually wrapping to some very largenumber), and pass the incorrect translation on to the wrappedfunction.
    
    原来的函数接受一个无符号整数，然而Python 'C' API只能提取有符号整数。如果我们试图向hello.greet传递一个负数，Boost.Python版会引发Python异常，而另一个则会继续：执行C++代码，将负数转换为无符号数（通常会变成一个很大的数），然后把不正确的转换结果传递给被封装的函数。
 *  That brings us to the second problem: if the C++ greet()function is called with a number greater than 2, it will throw anexception.  Typically, if a C++ exception propagates across theboundary with code generated by a 'C' compiler, it will cause acrash.  As you can see in the first version, there's no C++scaffolding there to prevent this from happening.  Functions wrappedby Boost.Python automatically include an exception-handling layerwhich protects Python users by translating unhandled C++ exceptionsinto a corresponding Python exception.
    
    这引起了第二个问题：如果输入一个大于2的参数，C++ greet()函数会抛出异常。典型的，如果C++异常传播时，跨越了'C'编译器生成的代码的边界，就会导致崩溃。正如你在第一个版本中所见，那儿没有防止崩溃的C++机制。而Boost.Python封装的函数自动包含了异常处理层，它把未处理的C++异常翻译成相应的Python异常，从而保护了Python用户。
 *  A slightly more-subtle limitation is that the argument conversionused in the Python 'C' API case can only get that integer x in*one way*.  PyArg\_ParseTuple can't convert Python long objects(arbitrary-precision integers) which happen to fit in an unsignedint but not in a signed long, nor will it ever handle awrapped C++ class with a user-defined implicit operator unsignedint() conversion. Boost.Python's dynamic type conversionregistry allows users to add arbitrary conversion methods.
    
    一个更微妙的限制是，Python 'C' API的参数转换只能以“*一种*”方式取得整数x。如果有一个Python long对象（任意精度整数），它的大小正好属于unsigned int，但不属于signed long，PyArg\_ParseTuple就不能对其进行转换。对于一个定义了operator unsigned int()，即用户自定义隐式转换的C++封装类，它同样无法处理。而Boost.Python的动态类型转换注册表允许用户添加任意的转换方法。

# [Library Overview][Library Overview 1] #

# 库概览 #

This section outlines some of the library's major features.  Except asneccessary to avoid confusion, details of library implementation areomitted.

本节简述了库的一些主要特性。在不影响理解的情况下，省略了库的实现细节。

## [Exposing Classes][Exposing Classes 1] ##

## 导出类 ##

C++ classes and structs are exposed with a similarly-terse interface.Given:

C++类和结构是用同样简洁的接口导出的。如有：

struct World
    {
         
        void set(std::string msg) { this->msg = msg; }
        std::string greet() { return msg; }
        std::string msg;
    };

The following code will expose it in our extension module:

以下代码会将它导出到扩展模块：

#include <boost/python.hpp>
    BOOST_PYTHON_MODULE(hello)
    {
         
        class_<World>("World")
            .def("greet", &World::greet)
            .def("set", &World::set)
        ;
    }

Although this code has a certain pythonic familiarity, peoplesometimes find the syntax bit confusing because it doesn't look likemost of the C++ code they're used to. All the same, this is juststandard C++.  Because of their flexible syntax and operatoroverloading, C++ and Python are great for defining domain-specific(sub)languages(DSLs), and that's what we've done in Boost.Python. To break it down:

尽管上述代码具有某种熟悉的Python风格，但语法还是有点令人迷惑，因为它看起来不像通常的C++代码。但是，这仍然是正确的标准C++。因为C++和Python具有灵活的语法和运算符重载，它们都很善于定义特定领域（子）语言（DSLs, domain-specific (sub)languages）。我们在Boost.Python里面就是定义了一个DSL。把代码拆开来看:

class_<World>("World")

constructs an unnamed object of type class\_<World> and passes"World" to its constructor.  This creates a new-style Python classcalled World in the extension module, and associates it with theC++ type World in the Boost.Python type conversion registry.  Wemight have also written:

构造了一个匿名对象，类型为class\_<World>，并把"World"传递给它的构造函数。这将在扩展模块里创建一个新型Python类World，并在Boost.Python的类型转换注册表里，把它和C++类型World关联起来。我们也可以这么写:

class_<World> w("World");

but that would've been more verbose, since we'd have to name wagain to invoke its def() member function:

但是那会显得更冗长，因为我们不得不再次通过w去调用它的def()成员函数：

w.def("greet", &World::greet)

There's nothing special about the location of the dot for memberaccess in the original example: C++ allows any amount of whitespace oneither side of a token, and placing the dot at the beginning of eachline allows us to chain as many successive calls to member functionsas we like with a uniform syntax.  The other key fact that allowschaining is that class\_<> member functions all return a referenceto \*this.

原来的例子里的点表示成员访问，它的位置没有什么特别的：因为C++允许标记（token）的两边可以有任意数量的空白符。把点放在每行的开始，允许我们以一致的句法，链式串接连续的成员函数调用，想串多少都行。允许链式调用的另一关键是，class\_<>的成员函数都返回对\*this的引用。

So the example is equivalent to:

因此本例等同于：

class_<World> w("World");
    w.def("greet", &World::greet);
    w.def("set", &World::set);

It's occasionally useful to be able to break down the components of aBoost.Python class wrapper in this way, but the rest of this articlewill stick to the terse syntax.

这种方式将Boost.Python类包装的部件都拆分开来了，能这样拆分有时候是有用的。但本文下面仍将坚持使用简洁格式。

For completeness, here's the wrapped class in use:

最后来看封装类的使用:

>>> import hello
    >>> planet = hello.World()
    >>> planet.set('howdy')
    >>> planet.greet()
    'howdy'

### [Constructors][Constructors 1] ###

### 构造函数 ###

Since our World class is just a plain struct, it has animplicit no-argument (nullary) constructor.  Boost.Python exposes thenullary constructor by default, which is why we were able to write:

由于我们的World类只是一个简单的struct，它有一个隐式的无参数的构造函数。Boost.Python默认会导出这个无参数的构造函数，所以我们可以这样写：

>>> planet = hello.World()

However, well-designed classes in any language may require constructorarguments in order to establish their invariants.  Unlike Python,where \_\_init\_\_ is just a specially-named method, In C++constructors cannot be handled like ordinary member functions.  Inparticular, we can't take their address: &World::World is anerror.  The library provides a different interface for specifyingconstructors.  Given:

然而，在任何语言里，对于设计良好的类，构造函数可能需要参数，以建立类的不变式（invariant）。Python的\_\_init\_\_只是一个特殊命名的方法，而C++的构造函数与Python不同，它不能像普通成员函数那样处理。特别是，我们不能取它的地址：&World::World是一个错误。Boost.Python库提供了一个不同的接口来指定构造函数。假设有:

struct World
    {
          
        World(std::string msg); // added constructor
        ...

we can modify our wrapping code as follows:

我们可以如下修改封装代码:

class_<World>("World", init<std::string>())
        ...

of course, a C++ class may have additional constructors, and we canexpose those as well by passing more instances of init<...> todef():

当然，C++类可能还有其他的构造函数，我们也可以导出它们，只需要向def()传入更多的init<...>实例:

class_<World>("World", init<std::string>())
        .def(init<double, double>())
        ...

Boost.Python allows wrapped functions, member functions, andconstructors to be overloaded to mirror C++ overloading.

Boost.Python封装的函数、成员函数，以及构造函数都可以重载，以映射C++中的重载。

### [Data Members and Properties][Data Members and Properties 1] ###

### 数据成员和属性 ###

Any publicly-accessible data members in a C++ class can be easilyexposed as either readonly or readwrite attributes:

C++中任何可公有访问的数据成员，都能轻易地封装成readonly或者readwrite属性:

class_<World>("World", init<std::string>())
        .def_readonly("msg", &World::msg)
        ...

and can be used directly in Python:

并直接在Python中使用:

>>> planet = hello.World('howdy')
    >>> planet.msg
    'howdy'

This does *not* result in adding attributes to the World instance\_\_dict\_\_, which can result in substantial memory savings whenwrapping large data structures.  In fact, no instance \_\_dict\_\_will be created at all unless attributes are explicitly added fromPython. Boost.Python owes this capability to the new Python 2.2 typesystem, in particular the descriptor interface and property type.

这*不会*在World实例\_\_dict\_\_中添加属性，从而在封装大型数据结构时节省大量的内存。实际上，根本不会创建实例\_\_dict\_\_，除非从Python显式添加属性。Boost.Python的这种能力归功于Python 2.2新的类型系统，尤其是描述符（descriptor）接口和property类型。

In C++, publicly-accessible data members are considered a sign of poordesign because they break encapsulation, and style guides usuallydictate the use of "getter" and "setter" functions instead.  InPython, however, \_\_getattr\_\_, \_\_setattr\_\_, and since 2.2,property mean that attribute access is just one morewell-encapsulated syntactic tool at the programmer's disposal.Boost.Python bridges this idiomatic gap by making Python propertycreation directly available to users.  If msg were private, wecould still expose it as attribute in Python as follows:

在C++中，人们认为，可公有访问的数据成员是设计糟糕的标志，因为它们破坏了封装性，并且风格指南通常指示使用“getter”和“setter”函数作为替代。然而在Python里，\_\_getattr\_\_、\_\_setattr\_\_，和2.2版出现的property意味着，属性访问仅仅是一种任由程序员选用的、封装性更好的语法工具。Boost.Python让用户可直接创建Python property，从而消除了二者语言习惯上的差异。即使msg是私有的，我们仍可把它导出为Python中的属性，如下：

class_<World>("World", init<std::string>())
        .add_property("msg", &World::greet, &World::set)
        ...

The example above mirrors the familiar usage of properties in Python2.2+:

上例等同于Python 2.2+里面熟悉的属性的用法：

>>> class World(object):
    ...     __init__(self, msg):
    ...         self.__msg = msg
    ...     def greet(self):
    ...         return self.__msg
    ...     def set(self, msg):
    ...         self.__msg = msg
    ...     msg = property(greet, set)

### [Operator Overloading][Operator Overloading 1] ###

### 运算符重载 ###

The ability to write arithmetic operators for user-defined types hasbeen a major factor in the success of both languages for numericalcomputation, and the success of packages like [NumPy][] attests to thepower of exposing operators in extension modules.  Boost.Pythonprovides a concise mechanism for wrapping operator overloads. Theexample below shows a fragment from a wrapper for the Boost rationalnumber library:

两种语言都能够为用户自定义类型编写算术运算符，这是它们在数值计算上获得成功的主要因素，并且，像[NumPy][]这样的软件包的成功证明了在扩展模块中导出运算符的威力。Boost.Python为封装运算符重载提供了简洁的机制。下面是Boost有理数库封装代码的片断：

class_<rational<int> >("rational_int")
      .def(init<int, int>()) // constructor, e.g. rational_int(3,4)
      .def("numerator", &rational<int>::numerator)
      .def("denominator", &rational<int>::denominator)
      .def(-self)        // __neg__ (unary minus)
      .def(self + self)  // __add__ (homogeneous)
      .def(self * self)  // __mul__
      .def(self + int()) // __add__ (heterogenous)
      .def(int() + self) // __radd__
      ...

The magic is performed using a simplified application of "expressiontemplates" [\[VELD1995\]][VELD1995], a technique originally developed foroptimization of high-performance matrix algebra expressions.  Theessence is that instead of performing the computation immediately,operators are overloaded to construct a type *representing* thecomputation.  In matrix algebra, dramatic optimizations are oftenavailable when the structure of an entire expression can be taken intoaccount, rather than evaluating each operation "greedily".Boost.Python uses the same technique to build an appropriate Pythonmethod object based on expressions involving self.

魔法的施展只是简单应用了“表达式模板（expression templates）”[\[VELD1995\]][VELD1995]，一种最初为高性能矩阵代数表达式优化而开发的技术。其精髓是，不是立即进行计算，而是利用运算符重载，来构造一个*代表*计算的类型。在矩阵代数里，当考虑整个表达式的结构，而不是“贪婪地”对每步运算求值时，经常可以获得显著的优化。Boost.Python使用了同样的技术，它用包含self的表达式，构建了一个适当的Python成员方法对象。

### [Inheritance][Inheritance 1] ###

### 继承 ###

C++ inheritance relationships can be represented to Boost.Python by addingan optional bases<...> argument to the class\_<...> templateparameter list as follows:

要在Boost.Python里描述C++继承关系，可以在class\_<...>模板参数列表里添加一个可选的bases<...>，如下:

class_<Derived, bases<Base1,Base2> >("Derived")
         ...

This has two effects:

这有两种作用：

1.  When the class\_<...> is created, Python type objectscorresponding to Base1 and Base2 are looked up inBoost.Python's registry, and are used as bases for the new PythonDerived type object, so methods exposed for the Python Base1and Base2 types are automatically members of the Derivedtype.  Because the registry is global, this works correctly even ifDerived is exposed in a different module from either of itsbases.
2.  C++ conversions from Derived to its bases are added to theBoost.Python registry.  Thus wrapped C++ methods expecting (apointer or reference to) an object of either base type can becalled with an object wrapping a Derived instance.  Wrappedmember functions of class T are treated as though they have animplicit first argument of T&, so these conversions areneccessary to allow the base class methods to be called for derivedobjects.

1.  当class\_<...>创建时，会在Boost.Python的注册表里查找Base1和Base2所对应的Python类型对象，并将它们作为新的Python Derived类型对象的基类，因此为Python的Base1和Base2类型导出的成员函数自动成为Derived类型的成员。因为注册表是全局的，所以Derived和它的基类可以在不同的模块中导出。
2.  在Boost.Python的注册表里，添加了从Derived到它的基类的C++转换。这样，封装了Derived实例的对象就可以调用其基类的方法，而该封装的C++方法本该由一个基类对象（指针或引用）来调用。类T的成员方法封装后，可视为它们具有一个隐含的第一参数T&，所以为了允许派生类对象调用基类方法，这些转换是必须的。

Of course it's possible to derive new Python classes from wrapped C++class instances.  Because Boost.Python uses the new-style classsystem, that works very much as for the Python built-in types.  Thereis one significant detail in which it differs: the built-in typesgenerally establish their invariants in their \_\_new\_\_ function, sothat derived classes do not need to call \_\_init\_\_ on the baseclass before invoking its methods :

当然，也可以从封装的C++类实例派生新的Python类。因为Boost.Python使用了新型类系统，从封装类派生就像是从Python内置类型派生一样。但有一个重大区别：内置类型一般在\_\_new\_\_函数里建立不变式，因此其派生类不需要调用基类的\_\_init\_\_：

>>> class L(list):
    ...      def __init__(self):
    ...          pass
    ...
    >>> L().reverse()
    >>>

Because C++ object construction is a one-step operation, C++ instancedata cannot be constructed until the arguments are available, in the\_\_init\_\_ function:

因为C++的对象构造是一个单步操作，在\_\_init\_\_函数里，只有参数齐全，才能构造C++实例数据：

>>> class D(SomeBoostPythonClass):
    ...      def __init__(self):
    ...          pass
    ...
    >>> D().some_boost_python_method()
    Traceback (most recent call last):
      File "<stdin>", line 1, in ?
    TypeError: bad argument type for built-in operation

This happened because Boost.Python couldn't find instance data of typeSomeBoostPythonClass within the D instance; D's \_\_init\_\_function masked construction of the base class.  It could be correctedby either removing D's \_\_init\_\_ function or having it callSomeBoostPythonClass.\_\_init\_\_(...) explicitly.

发生错误的原因是，Boost.Python在实例D中，找不到类型SomeBoostPythonClass的实例数据；D的\_\_init\_\_函数遮盖了基类的构造函数。纠正方法为，删除D的\_\_init\_\_函数，或者让它显式调用SomeBoostPythonClass.\_\_init\_\_(...)。

### [Virtual Functions][Virtual Functions 1] ###

### 虚函数 ###

Deriving new types in Python from extension classes is not veryinteresting unless they can be used polymorphically from C++.  Inother words, Python method implementations should appear to overridethe implementation of C++ virtual functions when called *through baseclass pointers/references from C++*.  Since the only way to alter thebehavior of a virtual function is to override it in a derived class,the user must build a special derived class to dispatch a polymorphicclass' virtual functions:

用Python从扩展类派生新的类型没有太大意思，除非可以在C++里面多态地使用派生类。换句话说，*在C++里，通过基类指针或引用*调用C++虚函数时，Python实现的方法应该看起来像是覆盖了C++虚函数的实现。因为改变虚函数行为的唯一方法是，在派生类里覆盖它，所以用户必须构建一个特殊的派生类，来分派多态类的虚函数:

//
    // interface to wrap:
    //
    class Base
    {
          
     public:
        virtual int f(std::string x) { return 42; }
        virtual ~Base();
    };
    
    int calls_f(Base const& b, std::string x) { return b.f(x); }
    
    //
    // Wrapping Code
    //
    
    // Dispatcher class
    struct BaseWrap : Base
    {
          
        // Store a pointer to the Python object
        BaseWrap(PyObject* self_) : self(self_) {}
        PyObject* self;
    
        // Default implementation, for when f is not overridden
        int f_default(std::string x) { return this->Base::f(x); }
        // Dispatch implementation
        int f(std::string x) { return call_method<int>(self, "f", x); }
    };
    
    ...
        def("calls_f", calls_f);
        class_<Base, BaseWrap>("Base")
            .def("f", &Base::f, &BaseWrap::f_default)
            ;

Now here's some Python code which demonstrates:

这是Python演示代码：

>>> class Derived(Base):
    ...     def f(self, s):
    ...          return len(s)
    ...
    >>> calls_f(Base(), 'foo')
    42
    >>> calls_f(Derived(), 'forty-two')
    9

Things to notice about the dispatcher class:

关于分派类需要注意：

*  The key element which allows overriding in Python is thecall\_method invocation, which uses the same global typeconversion registry as the C++ function wrapping does to convert itsarguments from C++ to Python and its return type from Python to C++.
 *  Any constructor signatures you wish to wrap must be replicated withan initial PyObject\* argument
 *  The dispatcher must store this argument so that it can be used toinvoke call\_method
 *  The f\_default member function is needed when the function beingexposed is not pure virtual; there's no other way Base::f can becalled on an object of type BaseWrap, since it overrides f.

*  允许在Python里覆盖的关键因素是call\_method调用，与C++函数封装一样，它使用同一个全局注册表，把参数从C++转换到Python，并把返回类型从Python转换到C++。
 *  任何你希望封装的构造函数，其函数签名必须有一个的相同的初始化参数PyObject\*。
 *  分派者必须保存这个参数，以便调用call\_method时使用。
 *  当导出的函数不是纯虚函数时，就需要f\_default成员函数；在BaseWrap类型的对象里，没有其他方式可以调用Base::f，因为f被覆盖了。

### [Deeper Reflection on the Horizon?][Deeper Reflection on the Horizon 1] ###

### 更深的反射即将出现？ ###

Admittedly, this formula is tedious to repeat, especially on a projectwith many polymorphic classes.  That it is neccessary reflects somelimitations in C++'s compile-time introspection capabilities: there'sno way to enumerate the members of a class and find out which arevirtual functions.  At least one very promising project has beenstarted to write a front-end which can generate these dispatchers (andother wrapping code) automatically from C++ headers.

无可否认，重复这种公式化动作是冗长乏味的，尤其是项目里有大量多态类的时候。这里有必要反映一些C++编译时内省能力的限制：C++无法列举类的成员并找出虚函数。不过，至少有一个项目已经启动，有希望编写出一个前端程序，可以从C++头文件自动生成这些分派类（和其他封装代码），

[Pyste][] is being developed by Bruno da Silva de Oliveira.  It builds on[GCC\_XML][GCC_XML], which generates an XML version of GCC's internal programrepresentation.  Since GCC is a highly-conformant C++ compiler, thisensures correct handling of the most-sophisticated template code andfull access to the underlying type system.  In keeping with theBoost.Python philosophy, a Pyste interface description is neitherintrusive on the code being wrapped, nor expressed in some unfamiliarlanguage: instead it is a 100% pure Python script.  If Pyste issuccessful it will mark a move away from wrapping everything directlyin C++ for many of our users.  It will also allow us the choice toshift some of the metaprogram code from C++ to Python.  We expect thatsoon, not only our users but the Boost.Python developers themselveswill be "thinking hybrid" about their own code.

Bruno da Silva de Oliveira正在开发[Pyste][]。Pyste基于[GCC\_XML][GCC_XML]构建，而GCC\_XML可以生成XML版本的GCC内部程序描述。因为GCC是一种高度兼容标准的C++编译器，从而确保了对最复杂的模板代码的正确处理，和对底层类型系统的完全访问。和Boost.Python的哲学一致，Pyste接口描述既不侵入待封装的代码，也不使用某种不熟悉的语言来表达，相反，它是100%的纯Python脚本。如果Pyste成功的话，它将标志，我们的许多用户不必直接用C++封装所有东西。Pyste也将允许我们选择性地把一些元编程代码从C++转移到Python。我们期待不久以后，不仅用户，而且Boost.Python开发者也能，“混合地思考”他们自己的代码。（译注：Pyste已不再维护，更新的是[Py++][Py]。）

## [Serialization][Serialization 1] ##

## 序列化 ##

*Serialization* is the process of converting objects in memory to aform that can be stored on disk or sent over a network connection. Theserialized object (most often a plain string) can be retrieved andconverted back to the original object. A good serialization system willautomatically convert entire object hierarchies. Python's standardpickle module is just such a system.  It leverages the language's strongruntime introspection facilities for serializing practically arbitraryuser-defined objects. With a few simple and unintrusive provisions thispowerful machinery can be extended to also work for wrapped C++ objects.Here is an example:

*序列化（serialization）*是指，把内存中的对象转换成可保存格式，使之可以保存到磁盘上，或通过网络传送。序列化后的对象（最常见的是普通字符串），可以恢复并转换回原来的对象。好的序列化系统会自动转换整个对象层次结构。Python的标准模块pickle正是这样的系统。它利用了语言强大的运行时内省机制，可以序列化几乎任意的用户自定义对象。只需加入一些简单的、非侵入的处理，就可以扩展这个威力巨大的系统，使它也能用于封装的C++对象。下面是一个例子:

#include <string>
    
    struct World
    {
         
        World(std::string a_msg) : msg(a_msg) {}
        std::string greet() const { return msg; }
        std::string msg;
    };
    
    #include <boost/python.hpp>
    using namespace boost::python;
    
    struct World_picklers : pickle_suite
    {
         
      static tuple
      getinitargs(World const& w) { return make_tuple(w.greet()); }
    };
    
    BOOST_PYTHON_MODULE(hello)
    {
         
        class_<World>("World", init<std::string>())
            .def("greet", &World::greet)
            .def_pickle(World_picklers())
        ;
    }

Now let's create a World object and put it to rest on disk:

现在，让我们创建一个World对象并把它保存到磁盘：

>>> import hello
    >>> import pickle
    >>> a_world = hello.World("howdy")
    >>> pickle.dump(a_world, open("my_world", "w"))

In a potentially *different script* on a potentially *differentcomputer* with a potentially *different operating system*:

然后，可能是在不同的计算机、不同的操作系统上，一个脚本可能这样恢复对象：

>>> import pickle
    >>> resurrected_world = pickle.load(open("my_world", "r"))
    >>> resurrected_world.greet()
    'howdy'

Of course the cPickle module can also be used for fasterprocessing.

当然，使用cPickle模块可以更快速地处理。

Boost.Python's pickle\_suite fully supports the pickle protocoldefined in the standard Python documentation. Like a \_\_getinitargs\_\_function in Python, the pickle\_suite's getinitargs() is responsible forcreating the argument tuple that will be use to reconstruct the pickledobject.  The other elements of the Python pickling protocol,\_\_getstate\_\_ and \_\_setstate\_\_ can be optionally provided via C++getstate and setstate functions.  C++'s static type system allows thelibrary to ensure at compile-time that nonsensical combinations offunctions (e.g. getstate without setstate) are not used.

Boost.Python的pickle\_suite完全支持标准Python文档定义的pickle协议。类似Python里的\_\_getinitargs\_\_函数，pickle\_suite的getinitargs()负责创建参数元组，以重建pickle的对象。 Python pickle协议中的其他元素，\_\_getstate\_\_和\_\_setstate\_\_，可以通过C++ getstate和setstate函数来提供，也可以不提供。利用C++的静态类型系统，Boost.Python库在编译时保证，不会使用没有意义的函数组合（例如，有getstate无setstate）。

Enabling serialization of more complex C++ objects requires a littlemore work than is shown in the example above. Fortunately theobject interface (see next section) greatly helps in keeping thecode manageable.

要想序列化更复杂的C++对象，就需要做更多的工作。幸运的是，object接口（见下一节）帮了大忙，它保持了代码的可管理性。

## [Object interface][Object interface 1] ##

## Object接口 ##

Experienced 'C' language extension module authors will be familiarwith the ubiquitous PyObject\*, manual reference-counting, and theneed to remember which API calls return "new" (owned) references or"borrowed" (raw) references.  These constraints are not justcumbersome but also a major source of errors, especially in thepresence of exceptions.

对于有经验的'C'语言扩展模块的作者，他们应该熟悉无所不在的PyObject\*，手工引用计数，而且需要记住哪个API调用返回“新的”（拥有的）引用，哪个返回“借来的”（原始的）引用。这些约束不仅麻烦，而且是主要的错误源，尤其是面临异常的时候。

Boost.Python provides a class object which automates referencecounting and provides conversion to Python from C++ objects ofarbitrary type.  This significantly reduces the learning effort forprospective extension module writers.

Boost.Python提供了一个object类，它能够自动进行引用计数，并且能把任意类型的C++对象转换到Python。对于未来的扩展模块的编写者来说，这极大地减轻了学习的负担。

Creating an object from any other type is extremely simple:

从任何其他类型创建object极其简单:

object s("hello, world");  // s manages a Python string

object has templated interactions with all other types, withautomatic to-python conversions. It happens so naturally that it'seasily overlooked:

object和所有其他类型的交互，以及到Python的自动转换，都已经模板化了。这一切进行得如此自然，以至于可以轻松地忽略掉它：

object ten_Os = 10 * s[4]; // -> "oooooooooo"

In the example above, 4 and 10 are converted to Python objectsbefore the indexing and multiplication operations are invoked.

上例中，在调用索引和乘法操作之前，4和10被转换成了Python对象。

The extract<T> class template can be used to convert Python objectsto C++ types:

用类模板extract<T>可以把Python对象转换成C++类型：

double x = extract<double>(o);

If a conversion in either direction cannot be performed, anappropriate exception is thrown at runtime.

如果有一个方向的转换不能进行，则将在运行时抛出一个适当的异常。

The object type is accompanied by a set of derived typesthat mirror the Python built-in types such as list, dict,tuple, etc. as much as possible. This enables convenientmanipulation of these high-level types from C++:

除了object类型，还有一组派生类型，它们尽可能地对应于Python内置类型，如list、dict、tuple等等。这样就能方便地从C++操作这些高级类型了：

dict d;
    d["some"] = "thing";
    d["lucky_number"] = 13;
    list l = d.keys();

This almost looks and works like regular Python code, but it is pureC++.  Of course we can wrap C++ functions which accept or returnobject instances.

这看起来几乎就像是正规的Python代码，运行起来也像，但它是纯的C++。当然我们也能封装接受或返回object实例的C++函数。

# [Thinking hybrid][Thinking hybrid 1] #

# 混合地思考 #

Because of the practical and mental difficulties of combiningprogramming languages, it is common to settle a single language at theoutset of any development effort.  For many applications, performanceconsiderations dictate the use of a compiled language for the corealgorithms.  Unfortunately, due to the complexity of the static typesystem, the price we pay for runtime performance is often asignificant increase in development time.  Experience shows thatwriting maintainable C++ code usually takes longer and requires *far*more hard-earned working experience than developing comparable Pythoncode.  Even when developers are comfortable working exclusively incompiled languages, they often augment their systems by some type ofad hoc scripting layer for the benefit of their users without everavailing themselves of the same advantages.

因为混合语言编程具有事实上和心理上的困难，所以普通的做法是，在任何开发活动开始时，先确定一种单一语言。对很多应用来说，性能上的考虑决定了核心算法要用编译性语言实现。不幸的是，由于静态类型系统的复杂性，为了运行时的性能，我们所付出的代价常常是，开发时间大大增加。经验表明，和开发同等的Python代码相比，编写可维护的C++代码通常需要更长的时间，并且要求*多得*多的来之不易的工作经验。即使开发者觉得只用一门编译性语言挺好，为了用户的利益，他们也经常给他们的系统增加某种专门的脚本层，但是他们自己却从没利用这种好处。

Boost.Python enables us to *think hybrid*.  Python can be used forrapidly prototyping a new application; its ease of use and the largepool of standard libraries give us a head start on the way to aworking system.  If necessary, the working code can be used todiscover rate-limiting hotspots.  To maximize performance these canbe reimplemented in C++, together with the Boost.Python bindingsneeded to tie them back into the existing higher-level procedure.

Boost.Python让我们可以*混合地思考（think hybrid）*。Python可以为一个新应用快速搭建原型；在建立一个可运行的系统时，它的易用性和一大堆标准库让我们处于领先。如果有必要，可以用运行的代码来揭示限制速度的热点。为了提高性能，这些热点可以用C++来重新实现，然后用Boost.Python绑定，并提供给现有的高级过程调用。

Of course, this *top-down* approach is less attractive if it is clearfrom the start that many algorithms will eventually have to beimplemented in C++.  Fortunately Boost.Python also enables us topursue a *bottom-up* approach.  We have used this approach verysuccessfully in the development of a toolbox for scientificapplications.  The toolbox started out mainly as a library of C++classes with Boost.Python bindings, and for a while the growth wasmainly concentrated on the C++ parts.  However, as the toolbox isbecoming more complete, more and more newly added functionality can beimplemented in Python.

当然，如果从一开始就清楚，有许多算法将最终不得不用C++实现，这个*自上而下（top-down）*的方法就不是那么吸引人了。幸运的是，Boost.Python让我们也可以采用*自下而上（bottom-up）*的方法。我们曾经非常成功地应用这种方法，开发一个科学软件工具箱。开始的时候，这个工具箱主要是一个C++类库，并带有Boost.Python绑定，并且有一段时间，其成长主要集中在C++的部分。然而，当工具箱越来越完善，越来越多的新增功能可以用Python实现。

![python\_cpp\_mix.jpg][python_cpp_mix.jpg]

This figure shows the estimated ratio of newly added C++ and Pythoncode over time as new algorithms are implemented.  We expect thisratio to level out near 70% Python.  Being able to solve new problemsmostly in Python rather than a more difficult statically typedlanguage is the return on our investment in Boost.Python.  The abilityto access all of our code from Python allows a broader group ofdevelopers to use it in the rapid development of new applications.

该图显示，实现新的算法时，估计新增C++和Python代码的比率随时间的变化。我们预计这个比率会在接近70%的Python处变平。能够主要地用Python来解决新问题，而不是用更困难的静态类型语言，这是我们在Boost.Python上投入的回报。我们的所有代码都能从Python访问，这使得更多的开发者可以用它来快速开发新的应用。

# [Development history][Development history 1] #

# 开发历史 #

The first version of Boost.Python was developed in 2000 by DaveAbrahams at Dragon Systems, where he was privileged to have Tim Petersas a guide to "The Zen of Python".  One of Dave's jobs was to developa Python-based natural language processing system.  Since it waseventually going to be targeting embedded hardware, it was alwaysassumed that the compute-intensive core would be rewritten in C++ tooptimize speed and memory footprint [1][].  The project also wanted totest all of its C++ code using Python test scripts [2][].  The onlytool we knew of for binding C++ and Python was [SWIG][], and at the timeits handling of C++ was weak.  It would be false to claim any deepinsight into the possible advantages of Boost.Python's approach atthis point.  Dave's interest and expertise in fancy C++ templatetricks had just reached the point where he could do some real damage,and Boost.Python emerged as it did because it filled a need andbecause it seemed like a cool thing to try.

Boost.Python的第一版是由Dragon Systems的Dave Abrahams在2000年开发的，在Dragon Systems，Dave有幸由Tim Peters引导，接受了“Python之禅（The Zen of Python）”。Dave的工作之一是，开发基于Python的自然语言处理系统（NLP，natural language processing）。由于最终要用于嵌入式硬件，所以总是假设，计算密集的内核将会用C++来重写，以优化速度和内存占用[1][]。这个项目也想用Python测试脚本来测试所有的C++代码[2][]。当时，我们所知的绑定C++和Python的唯一工具是[SWIG][]，但那时它处理C++的能力比较弱。如果说在那时就有什么深知卓见，说Boost.Python的方法会有何等优越性，那是骗人的。那时，Dave正好对花俏的C++模板技巧感兴趣，并且娴熟到刚好能真正做点东西，Boost.Python就那样出现了，因为它满足了需求，因为它看起来挺酷，值得一试。

This early version was aimed at many of the same basic goals we'vedescribed in this paper, differing most-noticeably by having aslightly more cumbersome syntax and by lack of special support foroperator overloading, pickling, and component-based development.These last three features were quickly added by Ullrich Koethe andRalf Grosse-Kunstleve [3][], and other enthusiastic contributors arrivedon the scene to contribute enhancements like support for nestedmodules and static member functions.

这个早期版本针对的目标，与我们在本文所述的许多基本目标相同，最显著的区别在于，语法要稍微麻烦一点，并且，对运算符重载、pickling，和基于组件的开发缺乏专门的支持。后面这三个特性很快就由Ullrich Koethe和Ralf Grosse-Kunstleve加上了[3][]，并且，其他热心的贡献者也出现了，并作了一些改进，如对嵌套模块和静态成员函数的支持等。

By early 2001 development had stabilized and few new features werebeing added, however a disturbing new fact came to light: Ralf hadbegun testing Boost.Python on pre-release versions of a compiler usingthe [EDG][] front-end, and the mechanism at the core of Boost.Pythonresponsible for handling conversions between Python and C++ types wasfailing to compile.  As it turned out, we had been exploiting a verycommon bug in the implementation of all the C++ compilers we hadtested.  We knew that as C++ compilers rapidly became morestandards-compliant, the library would begin failing on moreplatforms.  Unfortunately, because the mechanism was so central to thefunctioning of the library, fixing the problem looked very difficult.

到2001年初，开发已经稳定下来了，很少有新增特性了，然而，这时出现了一件新的麻烦事：Ralf在一个使用[EDG][]前端的编译器的预发布版上测试Boost.Python，他发现，Boost.Python内核中，Python和C++类型转换机制无法通过编译。结果表明，我们一直是在利用一个错误，这是一个非常普遍的错误，存在于所有我们已经测试过的C++编译器的实现中。我们知道，随着C++编译器变得更加符合标准，很快，库将开始在更多的平台上失败。很不幸，因为这套机制是Boost.Python库功能的中枢，解决问题看起来非常困难。

Fortunately, later that year Lawrence Berkeley and later LawrenceLivermore National labs contracted with [Boost Consulting][] for supportand development of Boost.Python, and there was a new opportunity toaddress fundamental issues and ensure a future for the library.  Aredesign effort began with the low level type conversion architecture,building in standards-compliance and support for component-baseddevelopment (in contrast to version 1 where conversions had to beexplicitly imported and exported across module boundaries).  A newanalysis of the relationship between the Python and C++ objects wasdone, resulting in more intuitive handling for C++ lvalues andrvalues.

幸运的是，那一年末，Lawrence Berkeley，后来建立了Lawrence Livermore National labs，与[Boost Consulting][]签订了合同，来支持和发展Boost.Python，这样就有了一个新的机会来处理库的基本问题，从而确保了库未来的发展。库进行了重新设计，开始于底层的类型转换架构，使它内置具有标准兼容性，并支持基于组件的开发（第1版中，转换必须显式地在模块间导入和导出）。对Python和C++对象的关系进行了新的分析，从而能更直观地处理C++左值和右值。

The emergence of a powerful new type system in Python 2.2 made thechoice of whether to maintain compatibility with Python 1.5.2 easy:the opportunity to throw away a great deal of elaborate code foremulating classic Python classes alone was too good to pass up.  Inaddition, Python iterators and descriptors provided crucial andelegant tools for representing similar C++ constructs.  Thedevelopment of the generalized object interface allowed us tofurther shield C++ programmers from the dangers and syntactic burdensof the Python 'C' API.  A great number of other features including C++exception translation, improved support for overloaded functions, andmost significantly, CallPolicies for handling pointers andreferences, were added during this period.

关于是否维护对Python 1.5.2的兼容性，因为Python 2.2里出现了一个强大的新的类型系统，选择变得容易了：这个机会好的令人无法拒绝，籍此可以抛弃大量复杂精细的代码，而这些代码仅仅是用来模拟传统的Python类。另外，Python的迭代器（iterator）和描述符（descriptor）提供了重要且优雅的工具，用来表示类似的C++构造。通用的object接口的开发进一步方便了C++程序员，免除了Python 'C' API的危险性和语法负担。这一阶段，还添加了大量其他特性，包括C++异常翻译，对函数重载的更好的支持，还有最重要的，用来处理指针和引用的CallPolicies。

In October 2002, version 2 of Boost.Python was released.  Developmentsince then has concentrated on improved support for C++ runtimepolymorphism and smart pointers.  Peter Dimov's ingeniousboost::shared\_ptr design in particular has allowed us to give thehybrid developer a consistent interface for moving objects back andforth across the language barrier without loss of information.  Atfirst, we were concerned that the sophistication and complexity of theBoost.Python v2 implementation might discourage contributors, but theemergence of [Pyste][] and several other significant featurecontributions have laid those fears to rest.  Daily questions on thePython C++-sig and a backlog of desired improvements show that thelibrary is getting used.  To us, the future looks bright.

2002年十月，Boost.Python第2版发布了。从那以后，开发集中于更好地支持C++运行时多态性和智能指针。特别是Peter Dimov巧妙的boost::shared\_ptr 的设计，使我们能给混和系统开发者提供一个一致的接口，用于跨越语言屏障来回移动对象而不丢失信息。刚开始，我们担心Boost.Python v2实现的诡秘与复杂会阻碍贡献者，但[Pyste][]的出现，和其他几个重要特性的贡献，证明那些担心是多余的。在Python C++-sig上每天的提问，和积压的改进请求表明了库正在被使用。对我们来说，未来是光明的。

# [Conclusions][Conclusions 1] #

# 结论 #

Boost.Python achieves seamless interoperability between two rich andcomplimentary language environments.  Because it leverages templatemetaprogramming to introspect about types and functions, the usernever has to learn a third syntax: the interface definitions arewritten in concise and maintainable C++.  Also, the wrapping systemdoesn't have to parse C++ headers or represent the type system: thecompiler does that work for us.

Boost.Python在两种功能丰富并且互补的语言环境间实现了无缝协作。因为它利用模板元编程对类型和函数进行内省，用户不必去学习第三种语言：接口定义是用简洁和可维护的C++写的。同时，封装系统不必解析C++头文件或者描述类型系统：编译器都给我们做了。

Computationally intensive tasks play to the strengths of C++ and areoften impossible to implement efficiently in pure Python, while jobslike serialization that are trivial in Python can be very difficult inpure C++.  Given the luxury of building a hybrid software system fromthe ground up, we can approach design with new confidence and power.

计算密集型任务是C++的强项，一般不可能用纯Python高效实现，然而像序列化这样的工作，用Python很简单，用纯C++就非常困难。如果我们能构建完全的混合软件系统，我们就能以新的信心和力量来进行设计。

# [Citations][Citations 1] #

# 引用 #

<table>          
 <tbody> 
  <tr> 
   <td><a href="http://www.cppblog.com/jinq0123/admin/EditPosts.aspx?postid=51465#id1" rel="nofollow"><span style="COLOR: #000080; FONT-FAMILY: ">[VELD1995]</span></a></td> 
   <td>T. Veldhuizen, "Expression Templates," C++ Report,Vol. 7 No. 5 June 1995, pp. 26-31.<a href="http://osl.iu.edu/~tveldhui/papers/Expression-Templates/exprtmpl.html" rel="nofollow"><span style="COLOR: #000080; FONT-FAMILY: ">http://osl.iu.edu/~tveldhui/papers/Expression-Templates/exprtmpl.html</span></a></td> 
  </tr> 
 </tbody> 
</table>

# [Footnotes][Footnotes 1] #

# 脚注 #

<table>       
 <tbody> 
  <tr> 
   <td><a href="http://www.cppblog.com/jinq0123/admin/EditPosts.aspx?postid=51465#id2" rel="nofollow"><span style="COLOR: #000080; FONT-FAMILY: ">[1]</span></a></td> 
   <td>In retrospect, it seems that "thinking hybrid" from theground up might have been better for the NLP system: thenatural component boundaries defined by the pure pythonprototype turned out to be inappropriate for getting thedesired performance and memory footprint out of the C++ core,which eventually caused some redesign overhead on the Pythonside when the core was moved to C++. <p>回想起来，对NLP系统来说，从一开始就“混合地思考”可能会更好：用纯Python原型定义的组件接口，对Python来说是自然的，可后来发现并不合适。当核心改写成C++时，使用该接口无法达到期望的性能和内存占用要求，最后只好对Python这边的某些部分重新设计，造成了额外开销。</p> </td> 
  </tr> 
 </tbody> 
</table>

<table>       
 <tbody> 
  <tr> 
   <td><a href="http://www.cppblog.com/jinq0123/admin/EditPosts.aspx?postid=51465#id3" rel="nofollow"><span style="COLOR: #000080; FONT-FAMILY: ">[2]</span></a></td> 
   <td>We also have some reservations about driving all C++testing through a Python interface, unless that's the only wayit will be ultimately used.&nbsp; Any transition across languageboundaries with such different object models can inevitablymask bugs. <p>对于通过Python接口来驱动所有C++测试，我们也持保留态度，除非从Python调用是最终唯一的使用方式。因为两种语言的对象模型如此不同，任何跨越语言边界的转换都会不可避免地掩盖错误。</p> </td> 
  </tr> 
 </tbody> 
</table>

<table>       
 <tbody> 
  <tr> 
   <td><a href="http://www.cppblog.com/jinq0123/admin/EditPosts.aspx?postid=51465#id4" rel="nofollow"><span style="COLOR: #000080; FONT-FAMILY: ">[3]</span></a></td> 
   <td>These features were expressed very differently in v1 ofBoost.Python <p>这些特性在Boost.Python v1里表达方式非常不同。</p> </td> 
  </tr> 
 </tbody> 
</table>

# [http://www.boostpro.com/writing/bpl.html][http_www.boostpro.com_writing_bpl.html] #

# Building Hybrid Systems with Boost.Python #

<table>       
 <tbody> 
  <tr> 
   <th>Author:</th> 
   <td>David Abrahams</td> 
  </tr> 
  <tr> 
   <th>Contact:</th> 
   <td><a href="mailto:dave@boost-consulting.com" rel="nofollow">dave@boost-consulting.com</a></td> 
  </tr> 
  <tr> 
   <th>Organization:</th> 
   <td><a href="http://www.boost-consulting.com/" rel="nofollow">Boost Consulting</a></td> 
  </tr> 
  <tr> 
   <th>Date:</th> 
   <td>2003-03-19</td> 
  </tr> 
  <tr> 
   <th>Author:</th> 
   <td>Ralf W. Grosse-Kunstleve</td> 
  </tr> 
  <tr> 
   <th>Copyright:</th> 
   <td>Copyright David Abrahams and Ralf W. Grosse-Kunstleve 2003. All rights reserved</td> 
  </tr> 
 </tbody> 
</table>

Table of Contents

*  [Abstract][Abstract 2]
 *  [Introduction][Introduction 2]
 *  [Boost.Python Design Goals][Boost.Python Design Goals 2]
 *  [Hello Boost.Python World][Hello Boost.Python World 2]
 *  [Library Overview][Library Overview 2]
    
     *  [Exposing Classes][Exposing Classes 2]
        
         *  [Constructors][Constructors 2]
         *  [Data Members and Properties][Data Members and Properties 2]
         *  [Operator Overloading][Operator Overloading 2]
         *  [Inheritance][Inheritance 2]
         *  [Virtual Functions][Virtual Functions 2]
         *  [Deeper Reflection on the Horizon?][Deeper Reflection on the Horizon 2]
     *  [Serialization][Serialization 2]
     *  [Object interface][Object interface 2]
 *  [Thinking hybrid][Thinking hybrid 2]
 *  [Development history][Development history 2]
 *  [Conclusions][Conclusions 2]
 *  [Citations][Citations 2]
 *  [Footnotes][Footnotes 2]

# [Abstract][Abstract 3] #

Boost.Python is an open source C++ library which provides a concise IDL-like interface for binding C++ classes and functions to Python. Leveraging the full power of C++ compile-time introspection and of recently developed metaprogramming techniques, this is achieved entirely in pure C++, without introducing a new syntax. Boost.Python's rich set of features and high-level interface make it possible to engineer packages from the ground up as hybrid systems, giving programmers easy and coherent access to both the efficient compile-time polymorphism of C++ and the extremely convenient run-time polymorphism of Python.

# [Introduction][Introduction 3] #

Python and C++ are in many ways as different as two languages could be: while C++ is usually compiled to machine-code, Python is interpreted. Python's dynamic type system is often cited as the foundation of its flexibility, while in C++ static typing is the cornerstone of its efficiency. C++ has an intricate and difficult compile-time meta-language, while in Python, practically everything happens at runtime.

Yet for many programmers, these very differences mean that Python and C++ complement one another perfectly. Performance bottlenecks in Python programs can be rewritten in C++ for maximal speed, and authors of powerful C++ libraries choose Python as a middleware language for its flexible system integration capabilities. Furthermore, the surface differences mask some strong similarities:

*  'C'-family control structures (if, while, for...)
 *  Support for object-orientation, functional programming, and generic programming (these are both *multi-paradigm* programming languages.)
 *  Comprehensive operator overloading facilities, recognizing the importance of syntactic variability for readability and expressivity.
 *  High-level concepts such as collections and iterators.
 *  High-level encapsulation facilities (C++: namespaces, Python: modules) to support the design of re-usable libraries.
 *  Exception-handling for effective management of error conditions.
 *  C++ idioms in common use, such as handle/body classes and reference-counted smart pointers mirror Python reference semantics.

Given Python's rich 'C' interoperability API, it should in principle be possible to expose C++ type and function interfaces to Python with an analogous interface to their C++ counterparts. However, the facilities provided by Python alone for integration with C++ are relatively meager. Compared to C++ and Python, 'C' has only very rudimentary abstraction facilities, and support for exception-handling is completely missing. 'C' extension module writers are required to manually manage Python reference counts, which is both annoyingly tedious and extremely error-prone. Traditional extension modules also tend to contain a great deal of boilerplate code repetition which makes them difficult to maintain, especially when wrapping an evolving API.

These limitations have lead to the development of a variety of wrapping systems. [SWIG][] is probably the most popular package for the integration of C/C++ and Python. A more recent development is [SIP][], which was specifically designed for interfacing Python with the [Qt][] graphical user interface library. Both SWIG and SIP introduce their own specialized languages for customizing inter-language bindings. This has certain advantages, but having to deal with three different languages (Python, C/C++ and the interface language) also introduces practical and mental difficulties. The [CXX][] package demonstrates an interesting alternative. It shows that at least some parts of Python's 'C' API can be wrapped and presented through a much more user-friendly C++ interface. However, unlike SWIG and SIP, CXX does not include support for wrapping C++ classes as new Python types.

The features and goals of [Boost.Python][] overlap significantly with many of these other systems. That said, Boost.Python attempts to maximize convenience and flexibility without introducing a separate wrapping language. Instead, it presents the user with a high-level C++ interface for wrapping C++ classes and functions, managing much of the complexity behind-the-scenes with static metaprogramming. Boost.Python also goes beyond the scope of earlier systems by providing:

*  Support for C++ virtual functions that can be overridden in Python.
 *  Comprehensive lifetime management facilities for low-level C++ pointers and references.
 *  Support for organizing extensions as Python packages, with a central registry for inter-language type conversions.
 *  A safe and convenient mechanism for tying into Python's powerful serialization engine (pickle).
 *  Coherence with the rules for handling C++ lvalues and rvalues that can only come from a deep understanding of both the Python and C++ type systems.

The key insight that sparked the development of Boost.Python is that much of the boilerplate code in traditional extension modules could be eliminated using C++ compile-time introspection. Each argument of a wrapped C++ function must be extracted from a Python object using a procedure that depends on the argument type. Similarly the function's return type determines how the return value will be converted from C++ to Python. Of course argument and return types are part of each function's type, and this is exactly the source from which Boost.Python deduces most of the information required.

This approach leads to *user guided wrapping*: as much information is extracted directly from the source code to be wrapped as is possible within the framework of pure C++, and some additional information is supplied explicitly by the user. Mostly the guidance is mechanical and little real intervention is required. Because the interface specification is written in the same full-featured language as the code being exposed, the user has unprecedented power available when she does need to take control.

# [Boost.Python Design Goals][Boost.Python Design Goals 3] #

The primary goal of Boost.Python is to allow users to expose C++ classes and functions to Python using nothing more than a C++ compiler. In broad strokes, the user experience should be one of directly manipulating C++ objects from Python.

However, it's also important not to translate all interfaces *too* literally: the idioms of each language must be respected. For example, though C++ and Python both have an iterator concept, they are expressed very differently. Boost.Python has to be able to bridge the interface gap.

It must be possible to insulate Python users from crashes resulting from trivial misuses of C++ interfaces, such as accessing already-deleted objects. By the same token the library should insulate C++ users from low-level Python 'C' API, replacing error-prone 'C' interfaces like manual reference-count management and raw PyObject pointers with more-robust alternatives.

Support for component-based development is crucial, so that C++ types exposed in one extension module can be passed to functions exposed in another without loss of crucial information like C++ inheritance relationships.

Finally, all wrapping must be *non-intrusive*, without modifying or even seeing the original C++ source code. Existing C++ libraries have to be wrappable by third parties who only have access to header files and binaries.

# [Hello Boost.Python World][Hello Boost.Python World 3] #

And now for a preview of Boost.Python, and how it improves on the raw facilities offered by Python. Here's a function we might want to expose:

char const* greet(unsigned x)
    {
       static char const* const msgs[] = { "hello", "Boost.Python", "world!" };
    
       if (x > 2) 
           throw std::range_error("greet: index out of range");
    
       return msgs[x];
    }

To wrap this function in standard C++ using the Python 'C' API, we'd need something like this:

extern "C" // all Python interactions use 'C' linkage and calling convention
    {
        // Wrapper to handle argument/result conversion and checking
        PyObject* greet_wrap(PyObject* args, PyObject * keywords)
        {
             int x;
             if (PyArg_ParseTuple(args, "i", &x))    // extract/check arguments
             {
                 char const* result = greet(x);      // invoke wrapped function
                 return PyString_FromString(result); // convert result to Python
             }
             return 0;                               // error occurred
        }
    
        // Table of wrapped functions to be exposed by the module
        static PyMethodDef methods[] = {
            { "greet", greet_wrap, METH_VARARGS, "return one of 3 parts of a greeting" }
            , { NULL, NULL, 0, NULL } // sentinel
        };
    
        // module initialization function
        DL_EXPORT init_hello()
        {
            (void) Py_InitModule("hello", methods); // add the methods to the module
        }
    }

Now here's the wrapping code we'd use to expose it with Boost.Python:

#include <boost/python.hpp>
    using namespace boost::python;
    BOOST_PYTHON_MODULE(hello)
    {
        def("greet", greet, "return one of 3 parts of a greeting");
    }

and here it is in action:

>>> import hello
    >>> for x in range(3):
    ...     print hello.greet(x)
    ...
    hello
    Boost.Python
    world!

Aside from the fact that the 'C' API version is much more verbose, it's worth noting a few things that it doesn't handle correctly:

# [Library Overview][Library Overview 3] #

This section outlines some of the library's major features. Except as neccessary to avoid confusion, details of library implementation are omitted.

## [Exposing Classes][Exposing Classes 3] ##

C++ classes and structs are exposed with a similarly-terse interface. Given:

struct World
    {
        void set(std::string msg) { this->msg = msg; }
        std::string greet() { return msg; }
        std::string msg;
    };

The following code will expose it in our extension module:

#include <boost/python.hpp>
    BOOST_PYTHON_MODULE(hello)
    {
        class_<World>("World")
            .def("greet", &World::greet)
            .def("set", &World::set)
        ;
    }

Although this code has a certain pythonic familiarity, people sometimes find the syntax bit confusing because it doesn't look like most of the C++ code they're used to. All the same, this is just standard C++. Because of their flexible syntax and operator overloading, C++ and Python are great for defining domain-specific (sub)languages (DSLs), and that's what we've done in Boost.Python. To break it down:

class_<World>("World")

constructs an unnamed object of type class\_<World> and passes "World" to its constructor. This creates a new-style Python class called World in the extension module, and associates it with the C++ type World in the Boost.Python type conversion registry. We might have also written:

class_<World> w("World");

but that would've been more verbose, since we'd have to name w again to invoke its def() member function:

w.def("greet", &World::greet)

There's nothing special about the location of the dot for member access in the original example: C++ allows any amount of whitespace on either side of a token, and placing the dot at the beginning of each line allows us to chain as many successive calls to member functions as we like with a uniform syntax. The other key fact that allows chaining is that class\_<> member functions all return a reference to \*this.

So the example is equivalent to:

class_<World> w("World");
    w.def("greet", &World::greet);
    w.def("set", &World::set);

It's occasionally useful to be able to break down the components of a Boost.Python class wrapper in this way, but the rest of this article will stick to the terse syntax.

For completeness, here's the wrapped class in use:

>>> import hello
    >>> planet = hello.World()
    >>> planet.set('howdy')
    >>> planet.greet()
    'howdy'

### [Constructors][Constructors 3] ###

Since our World class is just a plain struct, it has an implicit no-argument (nullary) constructor. Boost.Python exposes the nullary constructor by default, which is why we were able to write:

>>> planet = hello.World()

However, well-designed classes in any language may require constructor arguments in order to establish their invariants. Unlike Python, where \_\_init\_\_ is just a specially-named method, In C++ constructors cannot be handled like ordinary member functions. In particular, we can't take their address: &World::World is an error. The library provides a different interface for specifying constructors. Given:

struct World
    {
        World(std::string msg); // added constructor
        ...

we can modify our wrapping code as follows:

class_<World>("World", init<std::string>())
        ...

of course, a C++ class may have additional constructors, and we can expose those as well by passing more instances of init<...> to def():

class_<World>("World", init<std::string>())
        .def(init<double, double>())
        ...

Boost.Python allows wrapped functions, member functions, and constructors to be overloaded to mirror C++ overloading.

### [Data Members and Properties][Data Members and Properties 3] ###

Any publicly-accessible data members in a C++ class can be easily exposed as either readonly or readwrite attributes:

class_<World>("World", init<std::string>())
        .def_readonly("msg", &World::msg)
        ...

and can be used directly in Python:

>>> planet = hello.World('howdy')
    >>> planet.msg
    'howdy'

This does *not* result in adding attributes to the World instance \_\_dict\_\_, which can result in substantial memory savings when wrapping large data structures. In fact, no instance \_\_dict\_\_ will be created at all unless attributes are explicitly added from Python. Boost.Python owes this capability to the new Python 2.2 type system, in particular the descriptor interface and property type.

In C++, publicly-accessible data members are considered a sign of poor design because they break encapsulation, and style guides usually dictate the use of "getter" and "setter" functions instead. In Python, however, \_\_getattr\_\_, \_\_setattr\_\_, and since 2.2, property mean that attribute access is just one more well-encapsulated syntactic tool at the programmer's disposal. Boost.Python bridges this idiomatic gap by making Python property creation directly available to users. If msg were private, we could still expose it as attribute in Python as follows:

class_<World>("World", init<std::string>())
        .add_property("msg", &World::greet, &World::set)
        ...

The example above mirrors the familiar usage of properties in Python 2.2+:

>>> class World(object):
    ...     __init__(self, msg):
    ...         self.__msg = msg
    ...     def greet(self):
    ...         return self.__msg
    ...     def set(self, msg):
    ...         self.__msg = msg
    ...     msg = property(greet, set)

### [Operator Overloading][Operator Overloading 3] ###

The ability to write arithmetic operators for user-defined types has been a major factor in the success of both languages for numerical computation, and the success of packages like [NumPy][] attests to the power of exposing operators in extension modules. Boost.Python provides a concise mechanism for wrapping operator overloads. The example below shows a fragment from a wrapper for the Boost rational number library:

class_<rational<int> >("rational_int")
      .def(init<int, int>()) // constructor, e.g. rational_int(3,4)
      .def("numerator", &rational<int>::numerator)
      .def("denominator", &rational<int>::denominator)
      .def(-self)        // __neg__ (unary minus)
      .def(self + self)  // __add__ (homogeneous)
      .def(self * self)  // __mul__
      .def(self + int()) // __add__ (heterogenous)
      .def(int() + self) // __radd__
      ...

The magic is performed using a simplified application of "expression templates" [\[VELD1995\]][VELD1995 1], a technique originally developed for optimization of high-performance matrix algebra expressions. The essence is that instead of performing the computation immediately, operators are overloaded to construct a type *representing* the computation. In matrix algebra, dramatic optimizations are often available when the structure of an entire expression can be taken into account, rather than evaluating each operation "greedily". Boost.Python uses the same technique to build an appropriate Python method object based on expressions involving self.

### [Inheritance][Inheritance 3] ###

C++ inheritance relationships can be represented to Boost.Python by adding an optional bases<...> argument to the class\_<...> template parameter list as follows:

class_<Derived, bases<Base1,Base2> >("Derived")
         ...

This has two effects:

1.  When the class\_<...> is created, Python type objects corresponding to Base1 and Base2 are looked up in Boost.Python's registry, and are used as bases for the new Python Derived type object, so methods exposed for the Python Base1 and Base2 types are automatically members of the Derived type. Because the registry is global, this works correctly even if Derived is exposed in a different module from either of its bases.
2.  C++ conversions from Derived to its bases are added to the Boost.Python registry. Thus wrapped C++ methods expecting (a pointer or reference to) an object of either base type can be called with an object wrapping a Derived instance. Wrapped member functions of class T are treated as though they have an implicit first argument of T&, so these conversions are neccessary to allow the base class methods to be called for derived objects.

Of course it's possible to derive new Python classes from wrapped C++ class instances. Because Boost.Python uses the new-style class system, that works very much as for the Python built-in types. There is one significant detail in which it differs: the built-in types generally establish their invariants in their \_\_new\_\_ function, so that derived classes do not need to call \_\_init\_\_ on the base class before invoking its methods :

>>> class L(list):
    ...      def __init__(self):
    ...          pass
    ...
    >>> L().reverse()
    >>>

Because C++ object construction is a one-step operation, C++ instance data cannot be constructed until the arguments are available, in the \_\_init\_\_ function:

>>> class D(SomeBoostPythonClass):
    ...      def __init__(self):
    ...          pass
    ...
    >>> D().some_boost_python_method()
    Traceback (most recent call last):
      File "<stdin>", line 1, in ?
    TypeError: bad argument type for built-in operation

This happened because Boost.Python couldn't find instance data of type SomeBoostPythonClass within the D instance; D's \_\_init\_\_ function masked construction of the base class. It could be corrected by either removing D's \_\_init\_\_ function or having it call SomeBoostPythonClass.\_\_init\_\_(...) explicitly.

### [Virtual Functions][Virtual Functions 3] ###

Deriving new types in Python from extension classes is not very interesting unless they can be used polymorphically from C++. In other words, Python method implementations should appear to override the implementation of C++ virtual functions when called *through base class pointers/references from C++*. Since the only way to alter the behavior of a virtual function is to override it in a derived class, the user must build a special derived class to dispatch a polymorphic class' virtual functions:

//
    // interface to wrap:
    //
    class Base
    {
     public:
        virtual int f(std::string x) { return 42; }
        virtual ~Base();
    };
    
    int calls_f(Base const& b, std::string x) { return b.f(x); }
    
    //
    // Wrapping Code
    //
    
    // Dispatcher class
    struct BaseWrap : Base
    {
        // Store a pointer to the Python object
        BaseWrap(PyObject* self_) : self(self_) {}
        PyObject* self;
    
        // Default implementation, for when f is not overridden
        int f_default(std::string x) { return this->Base::f(x); }
        // Dispatch implementation
        int f(std::string x) { return call_method<int>(self, "f", x); }
    };
    
    ...
        def("calls_f", calls_f);
        class_<Base, BaseWrap>("Base")
            .def("f", &Base::f, &BaseWrap::f_default)
            ;

Now here's some Python code which demonstrates:

>>> class Derived(Base):
    ...     def f(self, s):
    ...          return len(s)
    ...
    >>> calls_f(Base(), 'foo')
    42
    >>> calls_f(Derived(), 'forty-two')
    9

Things to notice about the dispatcher class:

*  The key element which allows overriding in Python is the call\_method invocation, which uses the same global type conversion registry as the C++ function wrapping does to convert its arguments from C++ to Python and its return type from Python to C++.
 *  Any constructor signatures you wish to wrap must be replicated with an initial PyObject\* argument
 *  The dispatcher must store this argument so that it can be used to invoke call\_method
 *  The f\_default member function is needed when the function being exposed is not pure virtual; there's no other way Base::f can be called on an object of type BaseWrap, since it overrides f.

### [Deeper Reflection on the Horizon?][Deeper Reflection on the Horizon 3] ###

Admittedly, this formula is tedious to repeat, especially on a project with many polymorphic classes. That it is neccessary reflects some limitations in C++'s compile-time introspection capabilities: there's no way to enumerate the members of a class and find out which are virtual functions. At least one very promising project has been started to write a front-end which can generate these dispatchers (and other wrapping code) automatically from C++ headers.

[Pyste][] is being developed by Bruno da Silva de Oliveira. It builds on [GCC\_XML][GCC_XML], which generates an XML version of GCC's internal program representation. Since GCC is a highly-conformant C++ compiler, this ensures correct handling of the most-sophisticated template code and full access to the underlying type system. In keeping with the Boost.Python philosophy, a Pyste interface description is neither intrusive on the code being wrapped, nor expressed in some unfamiliar language: instead it is a 100% pure Python script. If Pyste is successful it will mark a move away from wrapping everything directly in C++ for many of our users. It will also allow us the choice to shift some of the metaprogram code from C++ to Python. We expect that soon, not only our users but the Boost.Python developers themselves will be "thinking hybrid" about their own code.

## [Serialization][Serialization 3] ##

*Serialization* is the process of converting objects in memory to a form that can be stored on disk or sent over a network connection. The serialized object (most often a plain string) can be retrieved and converted back to the original object. A good serialization system will automatically convert entire object hierarchies. Python's standard pickle module is just such a system. It leverages the language's strong runtime introspection facilities for serializing practically arbitrary user-defined objects. With a few simple and unintrusive provisions this powerful machinery can be extended to also work for wrapped C++ objects. Here is an example:

#include <string>
    
    struct World
    {
        World(std::string a_msg) : msg(a_msg) {}
        std::string greet() const { return msg; }
        std::string msg;
    };
    
    #include <boost/python.hpp>
    using namespace boost::python;
    
    struct World_picklers : pickle_suite
    {
      static tuple
      getinitargs(World const& w) { return make_tuple(w.greet()); }
    };
    
    BOOST_PYTHON_MODULE(hello)
    {
        class_<World>("World", init<std::string>())
            .def("greet", &World::greet)
            .def_pickle(World_picklers())
        ;
    }

Now let's create a World object and put it to rest on disk:

>>> import hello
    >>> import pickle
    >>> a_world = hello.World("howdy")
    >>> pickle.dump(a_world, open("my_world", "w"))

In a potentially *different script* on a potentially *different computer* with a potentially *different operating system*:

>>> import pickle
    >>> resurrected_world = pickle.load(open("my_world", "r"))
    >>> resurrected_world.greet()
    'howdy'

Of course the cPickle module can also be used for faster processing.

Boost.Python's pickle\_suite fully supports the pickle protocol defined in the standard Python documentation. Like a \_\_getinitargs\_\_ function in Python, the pickle\_suite's getinitargs() is responsible for creating the argument tuple that will be use to reconstruct the pickled object. The other elements of the Python pickling protocol, \_\_getstate\_\_ and \_\_setstate\_\_ can be optionally provided via C++ getstate and setstate functions. C++'s static type system allows the library to ensure at compile-time that nonsensical combinations of functions (e.g. getstate without setstate) are not used.

Enabling serialization of more complex C++ objects requires a little more work than is shown in the example above. Fortunately the object interface (see next section) greatly helps in keeping the code manageable.

## [Object interface][Object interface 3] ##

Experienced 'C' language extension module authors will be familiar with the ubiquitous PyObject\*, manual reference-counting, and the need to remember which API calls return "new" (owned) references or "borrowed" (raw) references. These constraints are not just cumbersome but also a major source of errors, especially in the presence of exceptions.

Boost.Python provides a class object which automates reference counting and provides conversion to Python from C++ objects of arbitrary type. This significantly reduces the learning effort for prospective extension module writers.

Creating an object from any other type is extremely simple:

object s("hello, world");  // s manages a Python string

object has templated interactions with all other types, with automatic to-python conversions. It happens so naturally that it's easily overlooked:

object ten_Os = 10 * s[4]; // -> "oooooooooo"

In the example above, 4 and 10 are converted to Python objects before the indexing and multiplication operations are invoked.

The extract<T> class template can be used to convert Python objects to C++ types:

double x = extract<double>(o);

If a conversion in either direction cannot be performed, an appropriate exception is thrown at runtime.

The object type is accompanied by a set of derived types that mirror the Python built-in types such as list, dict, tuple, etc. as much as possible. This enables convenient manipulation of these high-level types from C++:

dict d;
    d["some"] = "thing";
    d["lucky_number"] = 13;
    list l = d.keys();

This almost looks and works like regular Python code, but it is pure C++. Of course we can wrap C++ functions which accept or return object instances.

# [Thinking hybrid][Thinking hybrid 3] #

Because of the practical and mental difficulties of combining programming languages, it is common to settle a single language at the outset of any development effort. For many applications, performance considerations dictate the use of a compiled language for the core algorithms. Unfortunately, due to the complexity of the static type system, the price we pay for runtime performance is often a significant increase in development time. Experience shows that writing maintainable C++ code usually takes longer and requires *far* more hard-earned working experience than developing comparable Python code. Even when developers are comfortable working exclusively in compiled languages, they often augment their systems by some type of ad hoc scripting layer for the benefit of their users without ever availing themselves of the same advantages.

Boost.Python enables us to *think hybrid*. Python can be used for rapidly prototyping a new application; its ease of use and the large pool of standard libraries give us a head start on the way to a working system. If necessary, the working code can be used to discover rate-limiting hotspots. To maximize performance these can be reimplemented in C++, together with the Boost.Python bindings needed to tie them back into the existing higher-level procedure.

Of course, this *top-down* approach is less attractive if it is clear from the start that many algorithms will eventually have to be implemented in C++. Fortunately Boost.Python also enables us to pursue a *bottom-up* approach. We have used this approach very successfully in the development of a toolbox for scientific applications. The toolbox started out mainly as a library of C++ classes with Boost.Python bindings, and for a while the growth was mainly concentrated on the C++ parts. However, as the toolbox is becoming more complete, more and more newly added functionality can be implemented in Python.

![python\_cpp\_mix.jpg][python_cpp_mix.jpg 1]

This figure shows the estimated ratio of newly added C++ and Python code over time as new algorithms are implemented. We expect this ratio to level out near 70% Python. Being able to solve new problems mostly in Python rather than a more difficult statically typed language is the return on our investment in Boost.Python. The ability to access all of our code from Python allows a broader group of developers to use it in the rapid development of new applications.

# [Development history][Development history 3] #

The first version of Boost.Python was developed in 2000 by Dave Abrahams at Dragon Systems, where he was privileged to have Tim Peters as a guide to "The Zen of Python". One of Dave's jobs was to develop a Python-based natural language processing system. Since it was eventually going to be targeting embedded hardware, it was always assumed that the compute-intensive core would be rewritten in C++ to optimize speed and memory footprint [1][1 1]. The project also wanted to test all of its C++ code using Python test scripts [2][2 1]. The only tool we knew of for binding C++ and Python was [SWIG][], and at the time its handling of C++ was weak. It would be false to claim any deep insight into the possible advantages of Boost.Python's approach at this point. Dave's interest and expertise in fancy C++ template tricks had just reached the point where he could do some real damage, and Boost.Python emerged as it did because it filled a need and because it seemed like a cool thing to try.

This early version was aimed at many of the same basic goals we've described in this paper, differing most-noticeably by having a slightly more cumbersome syntax and by lack of special support for operator overloading, pickling, and component-based development. These last three features were quickly added by Ullrich Koethe and Ralf Grosse-Kunstleve [3][3 1], and other enthusiastic contributors arrived on the scene to contribute enhancements like support for nested modules and static member functions.

By early 2001 development had stabilized and few new features were being added, however a disturbing new fact came to light: Ralf had begun testing Boost.Python on pre-release versions of a compiler using the [EDG][] front-end, and the mechanism at the core of Boost.Python responsible for handling conversions between Python and C++ types was failing to compile. As it turned out, we had been exploiting a very common bug in the implementation of all the C++ compilers we had tested. We knew that as C++ compilers rapidly became more standards-compliant, the library would begin failing on more platforms. Unfortunately, because the mechanism was so central to the functioning of the library, fixing the problem looked very difficult.

Fortunately, later that year Lawrence Berkeley and later Lawrence Livermore National labs contracted with [Boost Consulting][] for support and development of Boost.Python, and there was a new opportunity to address fundamental issues and ensure a future for the library. A redesign effort began with the low level type conversion architecture, building in standards-compliance and support for component-based development (in contrast to version 1 where conversions had to be explicitly imported and exported across module boundaries). A new analysis of the relationship between the Python and C++ objects was done, resulting in more intuitive handling for C++ lvalues and rvalues.

The emergence of a powerful new type system in Python 2.2 made the choice of whether to maintain compatibility with Python 1.5.2 easy: the opportunity to throw away a great deal of elaborate code for emulating classic Python classes alone was too good to pass up. In addition, Python iterators and descriptors provided crucial and elegant tools for representing similar C++ constructs. The development of the generalized object interface allowed us to further shield C++ programmers from the dangers and syntactic burdens of the Python 'C' API. A great number of other features including C++ exception translation, improved support for overloaded functions, and most significantly, CallPolicies for handling pointers and references, were added during this period.

In October 2002, version 2 of Boost.Python was released. Development since then has concentrated on improved support for C++ runtime polymorphism and smart pointers. Peter Dimov's ingenious boost::shared\_ptr design in particular has allowed us to give the hybrid developer a consistent interface for moving objects back and forth across the language barrier without loss of information. At first, we were concerned that the sophistication and complexity of the Boost.Python v2 implementation might discourage contributors, but the emergence of [Pyste][] and several other significant feature contributions have laid those fears to rest. Daily questions on the Python C++-sig and a backlog of desired improvements show that the library is getting used. To us, the future looks bright.

# [Conclusions][Conclusions 3] #

Boost.Python achieves seamless interoperability between two rich and complimentary language environments. Because it leverages template metaprogramming to introspect about types and functions, the user never has to learn a third syntax: the interface definitions are written in concise and maintainable C++. Also, the wrapping system doesn't have to parse C++ headers or represent the type system: the compiler does that work for us.

Computationally intensive tasks play to the strengths of C++ and are often impossible to implement efficiently in pure Python, while jobs like serialization that are trivial in Python can be very difficult in pure C++. Given the luxury of building a hybrid software system from the ground up, we can approach design with new confidence and power.

# [Citations][Citations 3] #

<table>          
 <tbody> 
  <tr> 
   <td><a href="http://writeblog.csdn.net/#id1" rel="nofollow">[VELD1995]</a></td> 
   <td>T. Veldhuizen, "Expression Templates," C++ Report, Vol. 7 No. 5 June 1995, pp. 26-31. <a href="http://osl.iu.edu/~tveldhui/papers/Expression-Templates/exprtmpl.html" rel="nofollow">http://osl.iu.edu/~tveldhui/papers/Expression-Templates/exprtmpl.html</a></td> 
  </tr> 
 </tbody> 
</table>

# [Footnotes][Footnotes 3] #

<table>       
 <tbody> 
  <tr> 
   <td><a href="http://writeblog.csdn.net/#id2" rel="nofollow">[1]</a></td> 
   <td>In retrospect, it seems that "thinking hybrid" from the ground up might have been better for the NLP system: the natural component boundaries defined by the pure python prototype turned out to be inappropriate for getting the desired performance and memory footprint out of the C++ core, which eventually caused some redesign overhead on the Python side when the core was moved to C++.</td> 
  </tr> 
 </tbody> 
</table>

<table>       
 <tbody> 
  <tr> 
   <td><a href="http://writeblog.csdn.net/#id3" rel="nofollow">[2]</a></td> 
   <td>We also have some reservations about driving all C++ testing through a Python interface, unless that's the only way it will be ultimately used. Any transition across language boundaries with such different object models can inevitably mask bugs.</td> 
  </tr> 
 </tbody> 
</table>

<table>       
 <tbody> 
  <tr> 
   <td><a href="http://writeblog.csdn.net/#id4" rel="nofollow">[3]</a></td> 
   <td>These features were expressed very differently in v1 of Boost.Python</td> 
  </tr> 
 </tbody> 
</table>

--------------------

[View document source][]. Generated on: 2003-03-19 03:31 UTC. Generated by [Docutils][] from [reStructuredText][] source.

[Building Hybrid Systems with Boost.Python]: http://www.boost-consulting.com/writing/bpl.html
[Abstract]: http://www.cppblog.com/jinq0123/admin/EditPosts.aspx?postid=51465#abstract
[Introduction]: http://www.cppblog.com/jinq0123/admin/EditPosts.aspx?postid=51465#introduction
[Boost.Python Design Goals]: http://www.cppblog.com/jinq0123/admin/EditPosts.aspx?postid=51465#boost-python-design-goals
[Hello Boost.Python World]: http://www.cppblog.com/jinq0123/admin/EditPosts.aspx?postid=51465#hello-boost-python-world
[Library Overview]: http://www.cppblog.com/jinq0123/admin/EditPosts.aspx?postid=51465#library-overview
[Exposing Classes]: http://www.cppblog.com/jinq0123/admin/EditPosts.aspx?postid=51465#exposing-classes
[Constructors]: http://www.cppblog.com/jinq0123/admin/EditPosts.aspx?postid=51465#constructors
[Data Members and Properties]: http://www.cppblog.com/jinq0123/admin/EditPosts.aspx?postid=51465#data-members-and-properties
[Operator Overloading]: http://www.cppblog.com/jinq0123/admin/EditPosts.aspx?postid=51465#operator-overloading
[Inheritance]: http://www.cppblog.com/jinq0123/admin/EditPosts.aspx?postid=51465#inheritance
[Virtual Functions]: http://www.cppblog.com/jinq0123/admin/EditPosts.aspx?postid=51465#virtual-functions
[Deeper Reflection on the Horizon]: http://www.cppblog.com/jinq0123/admin/EditPosts.aspx?postid=51465#deeper-reflection-on-the-horizon
[Serialization]: http://www.cppblog.com/jinq0123/admin/EditPosts.aspx?postid=51465#serialization
[Object interface]: http://www.cppblog.com/jinq0123/admin/EditPosts.aspx?postid=51465#object-interface
[Thinking hybrid]: http://www.cppblog.com/jinq0123/admin/EditPosts.aspx?postid=51465#thinking-hybrid
[Development history]: http://www.cppblog.com/jinq0123/admin/EditPosts.aspx?postid=51465#development-history
[Conclusions]: http://www.cppblog.com/jinq0123/admin/EditPosts.aspx?postid=51465#conclusions
[Citations]: http://www.cppblog.com/jinq0123/admin/EditPosts.aspx?postid=51465#citations
[Footnotes]: http://www.cppblog.com/jinq0123/admin/EditPosts.aspx?postid=51465#footnotes
[Abstract 1]: http://www.cppblog.com/jinq0123/admin/EditPosts.aspx?postid=51465#id5
[Introduction 1]: http://www.cppblog.com/jinq0123/admin/EditPosts.aspx?postid=51465#id6
[SWIG]: http://www.swig.org/
[SIP]: http://www.riverbankcomputing.co.uk/sip/index.php
[Qt]: http://www.trolltech.com/
[CXX]: http://cxx.sourceforge.net/
[Boost.Python]: http://www.boost.org/libs/python/doc
[Boost.Python Design Goals 1]: http://www.cppblog.com/jinq0123/admin/EditPosts.aspx?postid=51465#id7
[Hello Boost.Python World 1]: http://www.cppblog.com/jinq0123/admin/EditPosts.aspx?postid=51465#id8
[Library Overview 1]: http://www.cppblog.com/jinq0123/admin/EditPosts.aspx?postid=51465#id9
[Exposing Classes 1]: http://www.cppblog.com/jinq0123/admin/EditPosts.aspx?postid=51465#id10
[Constructors 1]: http://www.cppblog.com/jinq0123/admin/EditPosts.aspx?postid=51465#id11
[Data Members and Properties 1]: http://www.cppblog.com/jinq0123/admin/EditPosts.aspx?postid=51465#id12
[Operator Overloading 1]: http://www.cppblog.com/jinq0123/admin/EditPosts.aspx?postid=51465#id13
[NumPy]: http://www.pfdubois.com/numpy/
[VELD1995]: http://www.cppblog.com/jinq0123/admin/EditPosts.aspx?postid=51465#veld1995
[Inheritance 1]: http://www.cppblog.com/jinq0123/admin/EditPosts.aspx?postid=51465#id14
[Virtual Functions 1]: http://www.cppblog.com/jinq0123/admin/EditPosts.aspx?postid=51465#id15
[Deeper Reflection on the Horizon 1]: http://www.cppblog.com/jinq0123/admin/EditPosts.aspx?postid=51465#id16
[Pyste]: http://www.boost.org/libs/python/pyste
[GCC_XML]: http://www.gccxml.org/HTML/Index.html
[Py]: http://www.language-binding.net/pyplusplus/pyplusplus.html
[Serialization 1]: http://www.cppblog.com/jinq0123/admin/EditPosts.aspx?postid=51465#id17
[Object interface 1]: http://www.cppblog.com/jinq0123/admin/EditPosts.aspx?postid=51465#id18
[Thinking hybrid 1]: http://www.cppblog.com/jinq0123/admin/EditPosts.aspx?postid=51465#id19
[python_cpp_mix.jpg]: /images/20220731/c01e938a10164454a2f7d8a0ade08af6.png
[Development history 1]: http://www.cppblog.com/jinq0123/admin/EditPosts.aspx?postid=51465#id20
[1]: http://www.cppblog.com/jinq0123/admin/EditPosts.aspx?postid=51465#proto
[2]: http://www.cppblog.com/jinq0123/admin/EditPosts.aspx?postid=51465#test
[3]: http://www.cppblog.com/jinq0123/admin/EditPosts.aspx?postid=51465#feature
[EDG]: http://www.edg.com/
[Boost Consulting]: http://www.boost-consulting.com/
[Conclusions 1]: http://www.cppblog.com/jinq0123/admin/EditPosts.aspx?postid=51465#id21
[Citations 1]: http://www.cppblog.com/jinq0123/admin/EditPosts.aspx?postid=51465#id22
[Footnotes 1]: http://www.cppblog.com/jinq0123/admin/EditPosts.aspx?postid=51465#id23
[http_www.boostpro.com_writing_bpl.html]: http://www.boostpro.com/writing/bpl.html
[Abstract 2]: http://writeblog.csdn.net/#abstract
[Introduction 2]: http://writeblog.csdn.net/#introduction
[Boost.Python Design Goals 2]: http://writeblog.csdn.net/#boost-python-design-goals
[Hello Boost.Python World 2]: http://writeblog.csdn.net/#hello-boost-python-world
[Library Overview 2]: http://writeblog.csdn.net/#library-overview
[Exposing Classes 2]: http://writeblog.csdn.net/#exposing-classes
[Constructors 2]: http://writeblog.csdn.net/#constructors
[Data Members and Properties 2]: http://writeblog.csdn.net/#data-members-and-properties
[Operator Overloading 2]: http://writeblog.csdn.net/#operator-overloading
[Inheritance 2]: http://writeblog.csdn.net/#inheritance
[Virtual Functions 2]: http://writeblog.csdn.net/#virtual-functions
[Deeper Reflection on the Horizon 2]: http://writeblog.csdn.net/#deeper-reflection-on-the-horizon
[Serialization 2]: http://writeblog.csdn.net/#serialization
[Object interface 2]: http://writeblog.csdn.net/#object-interface
[Thinking hybrid 2]: http://writeblog.csdn.net/#thinking-hybrid
[Development history 2]: http://writeblog.csdn.net/#development-history
[Conclusions 2]: http://writeblog.csdn.net/#conclusions
[Citations 2]: http://writeblog.csdn.net/#citations
[Footnotes 2]: http://writeblog.csdn.net/#footnotes
[Abstract 3]: http://writeblog.csdn.net/#id5
[Introduction 3]: http://writeblog.csdn.net/#id6
[Boost.Python Design Goals 3]: http://writeblog.csdn.net/#id7
[Hello Boost.Python World 3]: http://writeblog.csdn.net/#id8
[Library Overview 3]: http://writeblog.csdn.net/#id9
[Exposing Classes 3]: http://writeblog.csdn.net/#id10
[Constructors 3]: http://writeblog.csdn.net/#id11
[Data Members and Properties 3]: http://writeblog.csdn.net/#id12
[Operator Overloading 3]: http://writeblog.csdn.net/#id13
[VELD1995 1]: http://writeblog.csdn.net/#veld1995
[Inheritance 3]: http://writeblog.csdn.net/#id14
[Virtual Functions 3]: http://writeblog.csdn.net/#id15
[Deeper Reflection on the Horizon 3]: http://writeblog.csdn.net/#id16
[Serialization 3]: http://writeblog.csdn.net/#id17
[Object interface 3]: http://writeblog.csdn.net/#id18
[Thinking hybrid 3]: http://writeblog.csdn.net/#id19
[python_cpp_mix.jpg 1]: http://writeblog.csdn.net/python_cpp_mix.jpg
[Development history 3]: http://writeblog.csdn.net/#id20
[1 1]: http://writeblog.csdn.net/#proto
[2 1]: http://writeblog.csdn.net/#test
[3 1]: http://writeblog.csdn.net/#feature
[Conclusions 3]: http://writeblog.csdn.net/#id21
[Citations 3]: http://writeblog.csdn.net/#id22
[Footnotes 3]: http://writeblog.csdn.net/#id23
[View document source]: http://writeblog.csdn.net/bpl.txt
[Docutils]: http://docutils.sourceforge.net/
[reStructuredText]: http://docutils.sourceforge.net/rst.html