[C++-sig] Re: C arrays solution

Niall Douglas s_sourceforge at nedprod.com
Tue Oct 14 03:22:39 CEST 2003


On 14 Oct 2003 at 1:00, Raoul Gough wrote:

> > I'm wrapping a large preexisting library which is not my own. It
> > uses many idioms which make translation into python hard which has
> > up until now made python wrappings for the library very tough to
> > maintain.
> 
> Now I'm beginning to understand :-) You can't re-use (for instance)
> boost::array because this library already does things its own way.

Precisely. It doesn't even use the STL and its authors have clearly 
stated that the STL is *not* *permitted* to enter the library. 
Furthermore while they'll agree to /minor/ changes, they won't go for 
anything more than trivial.

Also while they have python bindings which they use a lot (they like 
python), they are only for the stable release and not the development 
release and thus are very out of date. The existing bindings are 
generated using SWIG and are a real pain to keep up to date - indeed 
they are sufficiently convoluted that I believe one of the SWIG 
authors is the only one able to substantially modify them.

> >> Also, I wonder about the use of member
> >> function pointers - is there an easier way to get what you want?
> >
> > Not at all. Those member functions are the official interface for
> > accessing the array's contents. They must be called at run-time to
> > yield correct access.
> 
> It was more a question of how you inform your wrapper layer what
> functions should be called. e.g. you could use a traits class, which
> would take care of this on a per-type basis (assuming that the
> functions to call don't vary from one object to another).

Already thought of that and they do vary in name from container to 
container.

> Or you could
> just use function overloading, something like the indexing::begin()
> and indexing::end() functions for arrays.

That's interesting, but wouldn't it require a separate declaration of 
the required functions somewhere beforehand? The solution I chose 
means very minimal manual editing of pyste's output - in fact, I'm 
going to make it a diff file applied by scons after calling pyste.

> > Now I've explained, your thoughts on whether it would be of use to
> > others?
> 
> Well, it's starting to make more sense to me. In fact, I think there
> is already something similar to this which returns a Python iterator
> instead of an indexing::iterator_pair. IIRC it's called
> boost::python::range or similar. The iterator_pair (with the container
> suite) has far more functionality than a Python iterator, of course.

Does boost::python::range provide random access? I don't think it 
does.

Basically, I want to make C arrays available as lists to python. Your 
suite (and thank you for it) with my little extension appears to do 
this very nicely indeed.

For example, there's now no reason why a bitmap's contents cannot be 
directly manipulated by python eg; bitmapdata[4]=0xff puts a white 
pixel at (4,0) on the screen.

> To summarise: this boils down to a method for generating an
> iterator_pair from an arbitrary object which has some way of
> generating two iterators. Does that sound about right?

Nearly.

This boils down to a method for generating an iterator_pair from an 
arbitrary object providing no more than a pointer and a length. The 
pointer and length can be retrieved from any arbitrary function 
except ones which return the value through their parameters (a lambda 
wrap could fix these though).

Once I'm done with the overloads, you won't even need a container 
object. I have several static global arrays I need to provide to 
python.

Cheers,
Niall




-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 208 bytes
Desc: not available
URL: <http://mail.python.org/pipermail/cplusplus-sig/attachments/20031014/16da90d6/attachment.pgp>


More information about the Cplusplus-sig mailing list