diff --git a/doc/building.html b/doc/building.html index 9c0452e7..84657b7a 100644 --- a/doc/building.html +++ b/doc/building.html @@ -1,21 +1,21 @@ - Building a Module with Py_cpp + Building an Extension Module

c++boost.gif (8819 bytes)Building a Module with Py_cpp + src="../../../c++boost.gif" alt= "c++boost.gif (8819 bytes)">Building an Extension Module

- Right now, the only supported configuration is one in which the py_cpp + Right now, the only supported configuration is one in which the BPL source files are statically linked with the source for your extension module. You may first build them into a library and link it with your extension module source, but the effect is the same as compiling all the source files together. Some users have successfully built the - py_cpp sources into a shared library, and support for a shared library - build is planned, but not yet implemented. The py_cpp source files are: + sources into a shared library, and support for a shared library + build is planned, but not yet implemented. The BPL source files are: 

 extclass.cpp
@@ -29,6 +29,7 @@

+ Next: Enums Previous: A Peek Under the Hood Up: Top

diff --git a/doc/comparisons.html b/doc/comparisons.html index d0c31d9f..2590dae2 100644 --- a/doc/comparisons.html +++ b/doc/comparisons.html @@ -12,14 +12,16 @@

CXX

- Like py_cpp, CXX attempts to - provide a C++-oriented interface to Python. In most cases, like py_cpp, - it relieves the user from worrying about reference-counts. As far as I - can tell, there is no support for subclassing C++ extension types in - Python. An even more-significant difference is that a user's C++ code is - still basically “dealing with Python objects”, though they are wrapped - in C++ classes. This means such jobs as argument parsing and conversion - are still left to be done explicitly by the user. + Like BPL, CXX attempts to + provide a C++-oriented interface to Python. In most cases, as with the + boost library, it relieves the user from worrying about + reference-counts. Both libraries automatically convert thrown C++ + exceptions into Python exceptions. As far as I can tell, CXX has no + support for subclassing C++ extension types in Python. An even + more significant difference is that a user's C++ code is still basically + “dealing with Python objects”, though they are wrapped in + C++ classes. This means such jobs as argument parsing and conversion are + still left to be done explicitly by the user.

CXX claims to interoperate well with the C++ Standard Library @@ -38,11 +40,9 @@

As far as I can tell, CXX enables one to write what is essentially idiomatic Python code in C++, manipulating Python objects through the - same fully-generic interfaces we use in Python. I think it would be fair - to say that while you're not programming directly to the “bare - metal” with CXX, in comparison to py_cpp, it presents a low-level - interface to Python. That use is also supported by the py_cpp object - wrappers. + same fully-generic interfaces we use in Python. While you're hardly programming directly to the “bare + metal” with CXX, it basically presents a “C++-ized” + version of the Python 'C' API.

Paul F. Dubois, the original @@ -65,7 +65,7 @@ that.”
-Paul Dubois languages. Swig relies on a parser to read your source code and produce additional source code files which can be compiled into a Python (or Perl or Tcl) extension module. It has been successfully used to create - many Python extension modules. Like py_cpp, SWIG is trying to allow an + many Python extension modules. Like BPL, SWIG is trying to allow an existing interface to be wrapped with little or no change to the existing code. The documentation says “SWIG parses a form of ANSI C syntax that has been extended with a number of special directives. As a @@ -78,15 +78,15 @@ that.”
-Paul Dubois couldnt handle templates, didnt do func overloading properly etc. For ANSI C libraries this was fine. But for usual C++ code this was a problem. Simple things work. But for anything very complicated (or - realistic), one had to write code by hand. I believe py_cpp doesn't have + realistic), one had to write code by hand. I believe BPL doesn't have this problem[sic]... IMHO overloaded functions are very important to wrap correctly.”
-Prabhu Ramachandran

- By contrast, py_cpp doesn't attempt to parse C++ - the problem is simply + By contrast, BPL doesn't attempt to parse C++ - the problem is simply too complex to do correctly. Technically, one does - write code by hand to use py_cpp. The goal, however, has been to make + write code by hand to use BPL. The goal, however, has been to make that code nearly as simple as listing the names of the classes and member functions you want to expose in Python. @@ -95,7 +95,7 @@ that.”
-Paul Dubois SIP is a system similar to SWIG, though seemingly more - C++-oriented. The author says that like py_cpp, SIP supports overriding + C++-oriented. The author says that like BPL, SIP supports overriding extension class member functions in Python subclasses. It appears to have been designed specifically to directly support some features of PyQt/PyKDE, which is its primary client. Documentation is almost @@ -113,7 +113,7 @@ that.”
-Paul Dubois to a wide range of computer languages, including Common Lisp, C++, C, Modula-3, and Python. ILU can parse the ISL to generate a C++ language header file describing the interface, of which the user is expected to - provide an implementation. Unlike py_cpp, this means that the system + provide an implementation. Unlike BPL, this means that the system imposes implementation details on your C++ code at the deepest level. It is worth noting that some of the C++ names generated by ILU are supposed to be reserved to the C++ implementation. It is unclear from the @@ -148,7 +148,7 @@ an inheritance relationship?

Zope ExtensionClasses

- ExtensionClasses in Zope use the same underlying mechanism as py_cpp + ExtensionClasses in Zope use the same underlying mechanism as BPL to support subclassing of extension types in Python, including multiple-inheritance. Both systems support pickling/unpickling of extension class instances in very similar ways. Both systems rely on the @@ -159,30 +159,30 @@ an inheritance relationship? The major differences are:

+ Next: A Simple Example Using BPL Previous: A Brief Introduction to writing Python Extension Modules - Next: A Simple Example Using py_cpp Up: Top

© Copyright David Abrahams 2000. Permission to copy, use, modify, diff --git a/doc/enums.html b/doc/enums.html index 57aef35f..16277b03 100644 --- a/doc/enums.html +++ b/doc/enums.html @@ -8,31 +8,36 @@ c++boost.gif (8819 bytes)Wrapping enums +

Because there is in general no way to deduce that a value of arbitrary type T -is an enumeration constant, py_cpp cannot automatically convert enum values to -and from Python. To handle this case, you need to decide how you want the enum -to show up in Python (since Python doesn't have enums). Once you have done that, -you can write some simple from_python() and -to_python() functions. +is an enumeration constant, the Boost Python Library cannot automatically +convert enum values to and from Python. To handle this case, you need to decide +how you want the enum to show up in Python (since Python doesn't have +enums). Once you have done that, you can write some simple +from_python() and to_python() functions.

If you are satisfied with a Python int as a way to represent your enum -values, py_cpp provides a shorthand for these functions. You just need to +values, we provide a shorthand for these functions. You just need to instantiate boost::python::enum_as_int_converters<EnumType> where EnumType is your enumerated type. There are two convenient ways to do this: 

  1. +   ...
+} // close my_namespace
 // drop into namespace python and explicitly instantiate
 BOOST_PYTHON_BEGIN_CONVERSION_NAMESPACE // this is a gcc 2.95.2 bug workaround
   template class enum_as_int_converters;
 BOOST_PYTHON_END_CONVERSION_NAMESPACE
+namespace my_namespace { // re-open my_namespace
+   ...
 
  2.  // instantiate as base class in any namespace
 struct EnumTypeConverters
-    : boost::python::py_enum_as_int_converters
+    : boost::python::enum_as_int_converters<EnumType>
 {
 };
    @@ -82,6 +87,10 @@ my_class.add(boost::python::to_python(enum_value_1), "enum_value_1"); my_class.add(boost::python::to_python(enum_value_2), "enum_value_2"); ... +

    + Next: Pointers + Previous: Building an Extension Module + Up: Top

    © Copyright David Abrahams 2000. Permission to copy, use, modify, sell and distribute this document is granted provided this copyright diff --git a/doc/example1.html b/doc/example1.html index 9bf9e280..e39c3801 100644 --- a/doc/example1.html +++ b/doc/example1.html @@ -1,7 +1,7 @@ - A Simple Example Using py_cpp + A Simple Example Using BPL

    @@ -9,7 +9,7 @@ "c++boost.gif (8819 bytes)">

    - A Simple Example Using py_cpp + A Simple Example Using BPL

    Suppose we have the following C++ API which we want to expose in @@ -24,20 +24,20 @@ namespace hello {    public:       world(int);       ~world(); -      std::string get() const { return "hi, world"; } +      std::string greet() const { return "hi, world"; }     ...   }; -  std::size_t length(const world& x) { return std::strlen(x.get()); } +  std::size_t length(const world& x) { return std::strlen(x.greet()); } }

    Here is the C++ code for a python module called hello - which exposes the API using py_cpp: + which exposes the API using BPL: 

    -#include 
+#include <boost/python/class_builder.hpp>
 // Python requires an exported function called init<module-name> in every
 // extension module. This is where we build the module contents.
 extern "C"
@@ -49,15 +49,15 @@ void inithello()
     try
     {
        // create an object representing this extension module
-       boost::python::module_builder hello("hello");
+       boost::python::module_builder m("hello");
        // Create the Python type object for our extension class
-       boost::python::class_builder<hello::world> world_class(hello, "world");
+       boost::python::class_builder<hello::world> world_class(m, "world");
        // Add the __init__ function
        world_class.def(boost::python::constructor<int>());
        // Add a regular member function
        world_class.def(&hello::world::get, "get");
        // Add a regular function to the module
-       hello.def(hello::length, "length");
+       m.def(hello::length, "length");
     }
     catch(...)
     {
@@ -82,7 +82,7 @@ extern "C" BOOL WINAPI DllMain(HINSTANCE, DWORD, LPVOID)
 
     >>> import hello
 >>> hi_world = hello.world(3)
->>> hi_world.get()
+>>> hi_world.greet()
 'hi, world'
 >>> hello.length(hi_world)
 9
@@ -93,11 +93,11 @@ extern "C" BOOL WINAPI DllMain(HINSTANCE, DWORD, LPVOID)
       
    
 
     >>> class my_subclass(hello.world):
-...     def get(self):
+...     def greet(self):
 ...         return 'hello, world'
 ...
 >>> y = my_subclass(4)
->>> y.get()
+>>> y.greet()
 'hello, world'
 
    
       
    
@@ -115,7 +115,8 @@ extern "C" BOOL WINAPI DllMain(HINSTANCE, DWORD, LPVOID)
         to have a length() of 12? If so, read on...
       
    
-         Previous: Comparisons with other systems Next: Overridable virtual functions Up:
+        Next: Overridable virtual functions
+         Previous: Comparisons with other systems  Up:
         Top
       
    
          © Copyright David Abrahams 2000. Permission to copy, use, modify,
diff --git a/doc/extending.html b/doc/extending.html
index 47341389..c4a3a5e4 100644
--- a/doc/extending.html
+++ b/doc/extending.html
@@ -38,11 +38,11 @@
     
     This last item typically occupies a great deal of code in an extension
     module. Remember that Python is a completely dynamic language. A callable
-    object receives its arguments in a tuple; it is up to that object to
-    extract those arguments from the tuple, check their types, and raise
-    appropriate exceptions. There are numerous other tedious details that need
-    to be managed; too many to mention here. Py_cpp is designed to lift most of
-    that burden.
    
+    object receives its arguments in a tuple; it is up to that object to extract
+    those arguments from the tuple, check their types, and raise appropriate
+    exceptions. There are numerous other tedious details that need to be
+    managed; too many to mention here. The Boost Python Library is designed to
+    lift most of that burden.
    
     
    
      
     
    
@@ -56,10 +56,10 @@
       sublcassing the extension type. Aside from being tedious, it's not really
       the same as having a true class, because there's no way for the user to
       override a method of the extension type which is called from the
-      extension module. Py_cpp solves this problem by taking advantage of Python's metaclass
       feature to provide objects which look, walk, and hiss almost exactly
-      like regular Python classes. Py_cpp classes are actually cleaner than
+      like regular Python classes. BPL classes are actually cleaner than
       Python classes in some subtle ways; a more detailed discussion will
       follow (someday).
    
     
    Next: Comparisons with Other Systems Up: 
     
     
-      py_cpp Python/C++ binding documentation
+      The Boost Python Library (BPL)
     
     
    
        c++boost.gif (8819 bytes) py_cpp*
+      align="center" height="86">The Boost Python Library (BPL)
     
    
 
-    
    
-       The source code for py_cpp, including a MSVC demo project is available here. 
-
 
    Synopsis
    
     
    
-       py_cpp is a system for quickly and easily interfacing C++ code with Python such that the Python interface is
+      Use the Boost Python Library to quickly and easily export a C++ library to Python such that the Python interface is
       very similar to the C++ interface. It is designed to be minimally
       intrusive on your C++ design. In most cases, you should not have to alter
-      your C++ classes in any way in order to use them with py_cpp. The system
+      your C++ classes in any way in order to use them with BPL. The system
       should simply “reflect” your C++ classes and functions into
-      Python. The major features of py_cpp include support for:
+      Python. The major features of BPL include support for:
 
      
 
    • Subclassing extension types in Python
 
    • Overriding virtual functions in Python
@@ -32,7 +28,7 @@ among others.
 
 
 
      Supported Platforms
      
-
      py_cpp has been tested in the following configurations:
+
      BPL has been tested in the following configurations:
 
 
        
 
      • Against Python 1.5.2 using the following compiler/library: 
@@ -56,7 +52,7 @@ among others.
   href="mailto:rwgk@cci.lbl.gov">Ralf W. Grosse-Kunstleve] 
 
   
      • An upcoming release of Metrowerks CodeWarrior
-        Pro6 for Windows (the first release has a bug that's fatal to py_cpp)
+        Pro6 for Windows (the first release has a bug that's fatal to BPL)
   
      
 
      
 
    • Against Python 2.0 using the following compiler/library combinations:
@@ -67,18 +63,13 @@ among others.
 
    
 
 
-
    Py_cpp requires the boost libraries, and is
-      has been accepted for inclusion into the boost libraries pending “boostification“
-      (completion of the documentation, change in some naming conventions and
-      resolution of some namespace issues).
-
 
    Credits
    
 
      
-      
    • David Abrahams originated
-      and wrote py_cpp.
+      
    • David Abrahams originated
+      and wrote the library.
 
       
    • Ullrich Koethe
-      had independently developed a similar system. When he discovered py_cpp,
+      had independently developed a similar system. When he discovered BPL,
       he generously contributed countless hours of coding and much insight into
       improving it. He is responsible for an early version of the support for function overloading and wrote the support for
@@ -88,13 +79,13 @@ among others.
       exposing numeric operators, including
       a way to avoid explicit coercion by means of overloading.
 
-      
    • The members of the boost mailing list and the Python community supplied
-      invaluable early feedback. In particular, Ron Clarke, Mark Evans, Anton
-      Gluck, Ralf W. Grosse-Kunstleve, Prabhu Ramachandran, and Barry Scott took
-      the brave step of trying to use py_cpp while it was still in early stages
-      of development.
+      
    • The members of the boost mailing list and the Python community
+      supplied invaluable early feedback. In particular, Ron Clarke, Mark Evans,
+      Anton Gluck, Ralf W. Grosse-Kunstleve, Chuck Ingold, Prabhu Ramachandran,
+      and Barry Scott took the brave step of trying to use BPL while it was
+      still in early stages of development.
 
-      
    • The development of py_cpp wouldn't have been
+      
    • The development of BPL wouldn't have been
       possible without the generous support of Dragon Systems/Lernout and
       Hauspie, Inc who supported its development as an open-source project.
 
    
@@ -105,10 +96,10 @@ among others.
       
  3. A Brief Introduction to writing Python
         extension modules
 
-      
  4. Comparisons between py_cpp and other
+      
  5. Comparisons between BPL and other
         systems for extending Python
 
-      
  6. A Simple Example Using py_cpp
+      
  7. A Simple Example Using BPL
 
       
  8. Overridable Virtual Functions
 
@@ -120,11 +111,13 @@ among others.
 
       
  9. A Peek Under the Hood
 
-      
  10. Building a Module with Py_cpp
+      
  11. Building a Module with BPL
 
       
  12. Advanced Topics
 
         
      
+          
    1. Pickling
+
           
    2. class_builder<>
 
           
    3. enums
@@ -143,63 +136,17 @@ among others.
 
      
  
     
    
-       More sophisticated examples are given in
-      extclass_demo.cpp,  extclass_demo.h, and 
-      test_extclass.py in the source code
-      archive. There's much more here, and much more documentation to
-      come...
+      Documentation is a major ongoing project; assistance is greatly
+      appreciated! In the meantime, useful examples of every BPL feature should
+      be evident in the regression test files test/comprehensive.[py/hpp/cpp]
+
     
    
        Questions should be directed to the boost mailing list.
 
-    
    Naming Contest
    
-
-    
    
-       Yes, I know py_cpp is a lousy name. Problem is, the best names my puny
-      imagination can muster (IDLE and GRAIL) are taken, so I'm holding a
-      naming contest. First prize? You get to pick the name<0.2wink> and
-      you will be credited in the documentation. Names that have been suggested
-      so far include:
-    
      
-      
    • 
-        Py++
-      
    • 
-        Python++
-      
    • 
-        Coil
-      
    • 
-        SnakeSkin
-      
    • 
-        CCCP - Convert C++ 
-        Classes to Python
-      
    • 
-        C3PO - Convert C++
-        Classes to Python 
-        Objects
-      
    • 
-        PALIN - Python 
-        Augmented-Language 
-        INtegration
-      
    • 
-        CLEESE - C++ Language Extension Environment
-        Supremely Easy
-      
    • 
-        JONES - Just Obscenely Neat Extension
-        System
-      
    • 
-        C-thru
-      
    • 
-        SeamlessC
-      
    • 
-        BorderCrossing
-      
    • 
-        Perseus (because he solved a hairy problem involving snakes by using
-        reflection and was invisible most of the time).
-    
    
-    Please post or send me your suggestions!
    
-     
    
-     
     
    
        © Copyright David Abrahams 2000. Permission to copy, use, modify,
       sell and distribute this document is granted provided this copyright
diff --git a/doc/inheritance.html b/doc/inheritance.html
index 2dd8071b..d11899c8 100644
--- a/doc/inheritance.html
+++ b/doc/inheritance.html
@@ -12,11 +12,11 @@
 
    Inheritance in Python
    
 
       
    
-         Py_cpp extension classes support single and multiple-inheritance in
-         Python, just like regular Python classes. You can mix built-in Python
-         classes with py_cpp extension classes in a derived class' tuple of
-         bases. Whenever a py_cpp extension class is among the bases for a new
-         class in Python, the result is an extension class:
+         BPL extension classes support single and multiple-inheritance in
+         Python, just like regular Python classes. You can arbitrarily mix
+         built-in Python classes with extension classes in a derived class'
+         tuple of bases. Whenever a BPL extension class is among the bases for a
+         new class in Python, the result is an extension class:
 
    
 
     >>> class MyPythonClass:
@@ -37,7 +37,7 @@
 
 
    Reflecting C++ Inheritance Relationships
    
       
    
-        Py_cpp also allows us to represent C++ inheritance relationships so that
+        BPL also allows us to represent C++ inheritance relationships so that
         wrapped derived classes may be passed where values, pointers, or
         references to a base class are expected as arguments. The
         declare_base member function of
@@ -71,7 +71,11 @@ int get_derived_x(const Derived& d) {
     return d.x;
 }
     
    
-#include 
+#include <boost/python/class_builder.hpp>
+
+// namespace alias for code brevity
+namespace python = boost::python;
+
 extern "C"
 #ifdef _WIN32
 __declspec(dllexport)
@@ -80,13 +84,13 @@ void initmy_module()
 {
     try
     {
-       boost::python::module_builder my_module("my_module");
+       python::module_builder my_module("my_module");
 
-       boost::python::class_builder<Base> base_class(my_module, "Base");
-       base_class.def(boost::python::constructor<void>());
+       python::class_builder<Base> base_class(my_module, "Base");
+       base_class.def(python::constructor<void>());
 
-       boost::python::class_builder<Derived> derived_class(my_module, "Derived");
-       derived_class.def(boost::python::constructor<void>());
+       python::class_builder<Derived> derived_class(my_module, "Derived");
+       derived_class.def(python::constructor<void>());
        // Establish the inheritance relationship between Base and Derived
        derived_class.declare_base(base_class);
 
@@ -96,7 +100,7 @@ void initmy_module()
     }
     catch(...)
     {
-       boost::python::handle_exception();    // Deal with the exception for Python
+       python::handle_exception();    // Deal with the exception for Python
     }
 }
 
    
@@ -135,12 +139,12 @@ struct Base2 {};
 struct Derived2 { int f(); };
 
    
    ...
-   boost::python::class_builder<Base> base2_class(my_module, "Base2");
-   base2_class.def(boost::python::constructor<void>());
+   python::class_builder<Base> base2_class(my_module, "Base2");
+   base2_class.def(python::constructor<void>());
 
-   boost::python::class_builder<Derived2> derived2_class(my_module, "Derived2");
-   derived2_class.def(boost::python::constructor<void>());
-   derived_class.declare_base(base_class, boost::python::without_downcast);
+   python::class_builder<Derived2> derived2_class(my_module, "Derived2");
+   derived2_class.def(python::constructor<void>());
+   derived_class.declare_base(base_class, python::without_downcast);
 
    13.
    @@ -150,8 +154,8 @@ struct Derived2 { int f(); }; references, or values.

    + Next: Special Method and Operator Support Previous: Function Overloading - Next: Special Method Names Up: Top

    © Copyright David Abrahams 2000. Permission to copy, use, modify, diff --git a/doc/overloading.html b/doc/overloading.html index 6197b230..5c2c236d 100644 --- a/doc/overloading.html +++ b/doc/overloading.html @@ -113,8 +113,7 @@ namespace scope as Python member functions.

    Overload Resolution

    - The function overload resolution mechanism in py_cpp works as - follows: + The function overload resolution mechanism works as follows:

      @@ -141,8 +140,8 @@ namespace scope as Python member functions.

    - Prev: Overridable Virtual Functions - Next: Special Method Names + Next: Inheritance + Previous: Overridable Virtual Functions Up: Top

    © Copyright David Abrahams 2000. Permission to copy, use, modify, diff --git a/doc/overriding.html b/doc/overriding.html index f8810ca1..ae629580 100644 --- a/doc/overriding.html +++ b/doc/overriding.html @@ -17,7 +17,7 @@

    Example

    -

    In this example, it is assumed that world::get() is a virtual +

    In this example, it is assumed that world::greet() is a virtual member function: 

    @@ -26,7 +26,7 @@ class world
  public:
     world(int);
     virtual ~world();
-    virtual std::string get() const { return "hi, world"; }
+    virtual std::string greet() const { return "hi, world"; }
 };
    @@ -65,11 +65,11 @@ struct world_callback : world : world(x), m_self(self) {} - std::string get() const // 3 + std::string greet() const // 3 { return boost::python::callback<std::string>::call_method(m_self, "get"); } static std::string default_get(const hello::world& self) const // 4 - { return self.world::get(); } + { return self.world::greet(); } private: PyObject* m_self; // 1 }; @@ -94,7 +94,7 @@ world_class.def(&world::get, "get", &world_callback::default_get) 
     >>> class my_subclass(hello.world):
-...     def get(self):
+...     def greet(self):
 ...         return 'hello, world'
 ...
 >>> hello.length(my_subclass())
@@ -181,9 +181,9 @@ break the ODR).
 
     
    
-      Prev: A Simple Example Using py_cpp Next: Function Overloading Up: Top
+      Next: Function Overloading
+      Previous: A Simple Example Using py_cpp
+      Up: Top
     
    
       © Copyright David Abrahams 2000. Permission to copy, use, modify,
       sell and distribute this document is granted provided this copyright
diff --git a/doc/pointers.html b/doc/pointers.html
index fe30af0b..0d0a92dc 100644
--- a/doc/pointers.html
+++ b/doc/pointers.html
@@ -13,7 +13,7 @@
 
       
    
 In general, raw pointers passed to or returned from functions are problematic
-for py_cpp because pointers have too many potential meanings. Is it an iterator?
+for BPL because pointers have too many potential meanings. Is it an iterator?
 A pointer to a single element? An array? When used as a return value, is the
 caller expected to manage (delete) the pointed-to object or is the pointer
 really just a reference? If the latter, what happens to Python references to the
@@ -35,11 +35,9 @@ converted from/to Python strings.
 
 
    My first piece of advice to anyone with a case not covered above is
 “find a way to avoid the problem.” For example, if you have just one
-or two functions returning a pointer to a single (not an array of) const
-T* for some wrapped T, you may be able to write a “thin
-converting wrapper” over those two functions as follows (Since py_cpp
-converts const T& values to_python by copying the T
-into a new extension instance, Foo must have a public copy constructor):
+or two functions that return a pointer to an individual const
+T, and T is a wrapped class, you may be able to write a “thin
+converting wrapper” over those two functions as follows:
 
 
     const Foo* f(); // original function
@@ -47,6 +45,10 @@ const Foo& f_wrapper() { return *f(); }
   ...
 my_module.def(f_wrapper, "f");
 
    
+
    
+Foo must have a public copy constructor for this technique to work, since BPL
+converts const T& values to_python by copying the T
+value into a new extension instance.
 
 
    Dealing with the problem
    
 
@@ -118,7 +120,7 @@ return value. You can handle this case by returning a Python tuple:
 typedef unsigned ErrorCode;
 const char* f(int* in_out_x); // original function
  ...
-#include 
+#include <boost/python/objects.hpp>
 const boost::python::tuple f_wrapper(int in_x) { 
   const char* s = f(in_x); 
   return boost::python::tuple(s, in_x);
@@ -131,8 +133,9 @@ my_module.def(f_wrapper, "f");
 >>> str,out_x = f(3)
    - - +

    + Previous: Enums + Up: Top

    © Copyright David Abrahams 2000. Permission to copy, use, modify, sell and distribute this document is granted provided this copyright diff --git a/doc/special.html b/doc/special.html index 4c314fcf..7dd210ba 100644 --- a/doc/special.html +++ b/doc/special.html @@ -13,7 +13,7 @@ Overview

    - Py_cpp supports all of the standard special method names supported by real Python class instances except __complex__ (more on the reasons - Note that py_cpp also supports automatic wrapping of + Note that BPL also supports automatic wrapping of __str__ and __cmp__. This is explained in the next section and the Table of Automatically Wrapped Methods. @@ -113,7 +113,7 @@ foo_class.def(&to_string, "__str__"); href="http://www.pythonlabs.com/pub/www.python.org/doc/current/ref/numeric-types.html">numeric protocols. This is the basic same technique used to expose to_string() as __str__() above, and is covered in detail below. Py_cpp also supports + href="#numeric_manual">covered in detail below. BPL also supports automatic wrapping of numeric operators whenever they have already been defined in C++. @@ -170,7 +170,7 @@ a = i + b; bignum_class.def(boost::python::operators<boost::python::op_add>(), boost::python::right_operand<int>()); bignum_class.def(boost::python::operators<boost::python::op_add>(), boost::python::left_operand<int>()); - Py_cpp uses overloading to register several variants of the same + BPL uses overloading to register several variants of the same operation (more on this in the context of coercion). Again, several operators can be exported at once: 

    @@ -276,13 +276,13 @@ bignum_class.def(&rmod,  "__rmod__");
       coercion functions can be difficult if many type combinations must be
       supported. 
       
    
-        Py_cpp solves this problem the same way that C++ does: with overloading. This technique drastically
         simplifies the code neccessary to support operators: you just register
-        operators for all desired type combinations, and py_cpp automatically
+        operators for all desired type combinations, and BPL automatically
         ensures that the correct function is called in each case; there is no
         need for user-defined coercion functions. To enable operator
-        overloading, py_cpp provides a standard coercion which is implicitly
+        overloading, BPL provides a standard coercion which is implicitly
         registered whenever automatic operator wrapping is used.
       
    
         If you wrap all operator functions manually, but still want to use
@@ -354,7 +354,7 @@ bignum_class.def((ternary_function2)&power,  "__pow__");
 
       In the second variant, however, BigNum appears only as second
       argument, and in the last one it is the third argument. These functions
-      must be presented to py_cpp such that that the BigNum
+      must be presented to BPL such that that the BigNum
       argument appears in first position:
 
 
    @@ -381,7 +381,7 @@ Note that "__rrpow__" is an extension not present in plain Python.
 
 
    Table of Automatically Wrapped Methods
    
       
    
-         Py_cpp can automatically wrap the following 
          special methods:
 
@@ -755,13 +755,13 @@ KeyError: 2
 
    Customized Attribute Access
    
 
       
    
-        Just like built-in Python classes, py_cpp extension classes support special
         the usual attribute access methods __getattr__,
         __setattr__, and __delattr__.
         Because writing these functions can
         be tedious in the common case where the attributes being accessed are
-        known statically, py_cpp checks the special names
+        known statically, BPL checks the special names
 
       
      
         
    • 
@@ -777,7 +777,7 @@ KeyError: 2
       following shows how we can implement a “computed attribute” in Python: 
       
      
 
      ->>> class Range(AnyPy_cppExtensionClass):
+>>> class Range(AnyBPLExtensionClass):
 ...    def __init__(self, start, end):
 ...        self.start = start
 ...        self.end = end
@@ -793,7 +793,7 @@ KeyError: 2
          Direct Access to Data Members
       
       
      
-         Py_cpp uses the special 
+         BPL uses the special 
         __xxxattr__<name>__ functionality described above
         to allow direct access to data members through the following special
         functions on class_builder<> and 
@@ -873,9 +873,9 @@ if (PyInstance_Check(r)) { ...
 
      
       
      
       
      
-         Previous: Inheritance Next: A Peek Under the Hood Up: Top
+Next: A Peek Under the Hood
+Previous: Inheritance 
+Up: Top
       
      
          © Copyright David Abrahams and Ullrich Köthe 2000.
         Permission to copy, use, modify, sell and distribute this document is
diff --git a/doc/under-the-hood.html b/doc/under-the-hood.html
index 288021cf..902804d3 100644
--- a/doc/under-the-hood.html
+++ b/doc/under-the-hood.html
@@ -22,7 +22,7 @@
       "example1.html#add_world_class">add it to the module it goes into the
       module's dictionary to be looked up under the name "world".
     
      
-      Py_cpp uses C++'s template argument deduction mechanism to determine the
+      BPL uses C++'s template argument deduction mechanism to determine the
       types of arguments to functions (except constructors, for which we must
       provide an argument list
       because they can't be named in C++). Then, it calls the appropriate
@@ -48,8 +48,8 @@
       the top of your module's init function, then def the member
       functions later to avoid problems with inter-class dependencies.
     
      
-      Previous: Function Overloading
-      Next: Building a Module with Py_cpp
+      Next: Building a Module with BPL
+      Previous: Special Method and Operator Support
       Up: Top
     
      
       © Copyright David Abrahams 2000. Permission to copy, use, modify,