|
Boost Users : |
From: David Abrahams (dave_at_[hidden])
Date: 2003-09-16 10:20:09
Steve,
First, Boost.Python questions should go to the C++-sig
(http://www.boost.org/more/mailing_lists.htm#cplussig).
Second, The current CVS has some excellent work on presenting C++
containers as Python containers by Joel de Guzman and Raoul Gough (see
vector_indexing_suite). I really suggest you try this stuff; it could
save you lots of code and will almost surely work better for you than
what you've done by hand because it handles some very subtle issues of
Python object lifetime and validity correctly.
Steve Horne <steve_at_[hidden]> writes:
> I'm currently writing a set of container classes using Boost.Python to
> wrap an existing C++ library. Progress has been very good - not even
> two days and I've wrapped all the existing C++ methods (at least
> 100). But of course a library designed for C++ is not a library
> designed for Python. Job 2 is to make it more Pythonic.
>
> The current problem is implementing slicing in the __getitem__,
> __setitem__ and __delitem__ methods. These are already working with
> single keys. To handle slicing, I need to identify in the key object
> is a slice object. This is the sticking point right now.
>
> I can access the type of the object using p.attr ("__class__") - but
> how do I get access to the slice type object from __builtins__ in
> order to compare?
>
> I could probably use a workaround such as extracting and checking a
> string representation from p.attr ("__class__").str (), but it seems
> to me that the ability to import symbols from another module (whether
> __builtins__ or some other Python or extension module).
>
> This could reduce to the ability to convert a PyObject* to an object
> instance - even more useful for using any C API functions that don't
> have a Boost.Python wrapper - but there seems to be no obvious way to
> do this.
>
> In addition, my containers are currently declared as follows...
>
> class_<classname, boost::noncopyable>("classname")
> ...
> ;
>
> The boost::noncopyable is there because the containers don't have copy
> constructors due to certain issues using the library in
> C++. Therefore, I'd like to better understand the implications of
> this.
>
> For instance, in Python the copy constructor is often used to make
> copy the entire container (as opposed to just rebinding
> names). Presumably Boost.Python supports this using the C++ classes
> copy constructor. This raises the questions...
>
> 1. How can I create an object to return to Python, containing an
> instance of the C++ container, without removing
> boost::noncopyable? (I need to do this to implement slicing too)
>
> This, I think, is roughly what is done in the Inheritance section of
> the tutorial so I probably need something like the 'factory'
> function. So, to reduce it to a simple copy-function example, the
> following should be about right...
>
> Base* container::make_copy ()
> {
> container *temp = new container ();
> temp->do_copy (*this);
> return temp;
> }
>
> ...
>
> .def("make_copy", container::make_copy,
> return_value_policy<manage_new_object>())
>
> I think this should be right, but confidence is low.
>
> 2. How can I support the Python copy constructor without having a C++
> copy constructor.
>
>
>
> I'm using boost-1.30.2 with Python 2.2.3 and Visual Studio 7.
>
> Any advice would be appreciated. Thanks.
-- Dave Abrahams Boost Consulting www.boost-consulting.com
Boost-users list run by williamkempf at hotmail.com, kalb at libertysoft.com, bjorn.karlsson at readsoft.com, gregod at cs.rpi.edu, wekempf at cox.net