[C++-sig] Re: C arrays solution
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
> 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
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=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?
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
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Size: 208 bytes
Desc: not available
More information about the Cplusplus-sig