diff --git a/building.html b/building.html index 96fe6e90..a25f08e4 100644 --- a/building.html +++ b/building.html @@ -34,9 +34,9 @@

© Copyright David Abrahams 2000. Permission to copy, use, modify, sell and distribute this document is granted provided this copyright - notice appears in all copies. This document is provided "as is" without - express or implied warranty, and with no claim as to its suitability - for any purpose. + notice appears in all copies. This document is provided “as + is” without express or implied warranty, and with no claim as to + its suitability for any purpose.

Updated: Oct 30, 2000 diff --git a/comparisons.html b/comparisons.html index 84cda747..6f6bf65a 100644 --- a/comparisons.html +++ b/comparisons.html @@ -17,28 +17,33 @@ 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 + 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. This is not entirely a - bad thing, as you can do some Pythonic things with CXX (e.g. variable - and keyword arguments) that I haven't yet figured out how to enable with - py_cpp. -

- 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. That use is also - supported by the py_cpp object wrappers. CXX claims to interoperate well - with the C++ Standard Library (a.k.a. STL) by providing iterators into - Python Lists and Dictionaries, but the claim is unfortunately - unsupportable. The problem is that in general, access to Python sequence and - mapping elements through iterators requires the use of proxy objects as - the return value of iterator dereference operations. This usage - conflicts with the basic ForwardIterator requirements in + CXX claims to interoperate well with the C++ Standard Library + (a.k.a. STL) by providing iterators into Python Lists and Dictionaries, + but the claim is unfortunately unsupportable. The problem is that in + general, access to Python sequence and mapping elements through + iterators requires the use of proxy objects as the return value of + iterator dereference operations. This usage conflicts with the basic + ForwardIterator requirements in section 24.1.3 of the standard (dereferencing must produce a reference). Although you may be able to use these iterators with some operations in some standard library implementations, it is neither guaranteed to work nor portable. + +

+ 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. +

Paul F. Dubois, the original author of CXX, has told me that what I've described is only half of the @@ -46,11 +51,11 @@ fill in the other half. Here is his response to the commentary above:

-"My intention with CXX was not to do what you are doing. It was to enable a +“My intention with CXX was not to do what you are doing. It was to enable a person to write an extension directly in C++ rather than C. I figured others had the wrapping business covered. I thought maybe CXX would provide an easier target language for those making wrappers, but I never explored -that."
-Paul Dubois +that.”
-Paul Dubois

SWIG

@@ -62,20 +67,20 @@ that."
-Paul Dubois 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 existing interface to be wrapped with little or no change to the - existing code. The documentation says "SWIG parses a form of ANSI C + 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 result, interfaces are usually built by grabbing a header file and - tweaking it a little bit." For C++ interfaces, the tweaking has often + tweaking it a little bit.” For C++ interfaces, the tweaking has often proven to amount to more than just a little bit. One user writes: -
"The problem with swig (when I used it) is that it +
“The problem with swig (when I used it) is that it 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 this problem[sic]... IMHO overloaded functions are very important to - wrap correctly."
-Prabhu Ramachandran + wrap correctly.”
-Prabhu Ramachandran

@@ -119,7 +124,7 @@ that."
-Paul Dubois GRAD is another very ambitious project aimed at generating Python wrappers for - interfaces written in "legacy languages", among which C++ is the first one + interfaces written in “legacy languages”, among which C++ is the first one implemented. Like SWIG, it aims to parse source code and automatically generate wrappers, though it appears to take a more sophisticated approach to parsing in general and C++ in particular, so it should do a much better @@ -145,9 +150,11 @@ an inheritance relationship? ExtensionClasses in Zope use the same underlying mechanism as py_cpp to support subclassing of extension types in Python, including - multiple-inheritance. Both systems rely on the same "Don - Beaudry Hack" that also inspired Don's MESS System. + Beaudry Hack” that also inspired Don's MESS System.

The major differences are:

@@ -148,9 +147,9 @@ namespace scope as Python member functions.

© Copyright David Abrahams 2000. Permission to copy, use, modify, sell and distribute this document is granted provided this copyright - notice appears in all copies. This document is provided "as is" without - express or implied warranty, and with no claim as to its suitability - for any purpose. + notice appears in all copies. This document is provided “as + is” without express or implied warranty, and with no claim as to + its suitability for any purpose.

Updated: Nov 21, 2000 diff --git a/overriding.html b/overriding.html index 0b2668fe..2a1ba70b 100644 --- a/overriding.html +++ b/overriding.html @@ -12,7 +12,7 @@ In the previous example we exposed a simple C++ class in Python and showed that we could write a subclass. We even redefined one of the functions in our derived class. Now we will learn - how to make the function behave virtually. + how to make the function behave virtually when called from C++.

Example

@@ -26,7 +26,7 @@ class world public:    world(int);     virtual ~world(); -    virtual const char* get() const { return "hi, world"; } +    virtual std::string get() const { return "hi, world"; } };
@@ -37,23 +37,24 @@ class world
    -
  1. A PyObject* data member that holds a reference to the - corresponding Python object. +
  2. A PyObject* data member that holds a + reference to the corresponding Python object. -
  3. A constructor for each exposed constructor of the base class which stores an - additional initial PyObject* argument in the data - member described above. +
  4. A constructor for each exposed constructor of the + base class which stores an additional initial PyObject* argument + in the data member described above. -
  5. An implementation of each virtual function you may wish to override in - Python which uses - python::callback<return-type>::call_method() to call the - Python override. +
  6. An implementation of each virtual function you may + wish to override in Python which uses + python::callback<return-type>::call_method() to call + the Python override. -
  7. For each non-pure virtual function meant to be overridable from Python, a - static member function (or a free function) taking a reference or pointer to the - base type as the first parameter and which forwards any additional parameters - neccessary to the default implementation of the virtual function. See also - this note if the base class virtual function is private. +
  8. For each non-pure virtual function meant to be + overridable from Python, a static member function (or a free function) taking + a reference or pointer to the base type as the first parameter and which + forwards any additional parameters neccessary to the default + implementation of the virtual function. See also this + note if the base class virtual function is private.
@@ -64,10 +65,10 @@ struct world_callback : world : world(x), m_self(self) {} - const char* get() const // 3 - { return python::callback<const char*>::call_method(m_self, "get"); } + std::string get() const // 3 + { return python::callback<std::string>::call_method(m_self, "get"); } - static const char* default_get(const hello::world& self) const // 4 + static std::string default_get(const hello::world& self) const // 4 { return self.world::get(); } private: PyObject* m_self; // 1 @@ -112,15 +113,15 @@ world_class.def(&world::get, "get", &world_callback::default_get)

Pure Virtual Functions

- A pure virtual function with no implementation is actually a lot easier - to deal with than a virtual function with a default implementation. First - of all, you obviously don't need to - supply a default implementation. Secondly, you don't need to call + A pure virtual function with no implementation is actually a lot easier to + deal with than a virtual function with a default implementation. First of + all, you obviously don't need to supply + a default implementation. Secondly, you don't need to call def() on the extension_class<> instance for the virtual function. In fact, you wouldn't want to: if the - corresponding attribute on the Python class stays undefined, you'll get - an AttributeError in Python when you try to call the - function, indicating that it should have been implemented. For example: + corresponding attribute on the Python class stays undefined, you'll get an + AttributeError in Python when you try to call the function, + indicating that it should have been implemented. For example: 

 struct baz {
diff --git a/pointers.html b/pointers.html
index c2fbdade..fb133740 100644
--- a/pointers.html
+++ b/pointers.html
@@ -8,7 +8,9 @@
          c++boost.gif (8819 bytes)Pointers
       
-
The Problem With Pointers

+
+
The Problem With Pointers

+
       

 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?
@@ -32,10 +34,10 @@ converted from/to Python strings.
 
Can you avoid the problem?

 
 
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
+“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
+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):
 
diff --git a/py_cpp.html b/py_cpp.html
index f38b61cb..15bd7049 100644
--- a/py_cpp.html
+++ b/py_cpp.html
@@ -20,8 +20,16 @@
       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
-      should simply "reflect" your C++ classes and functions into
-      Python.
+      should simply “reflect” your C++ classes and functions into
+      Python. The major features of py_cpp include support for:
+

+among others.
+
 
 
Supported Platforms

 
py_cpp has been tested in the following configurations:
@@ -60,12 +68,11 @@
 
 
 
Py_cpp requires the boost libraries, and is
-      has been accepted for inclusion into the boost libraries pending "boostification"
+      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

-