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

[Niall Douglas]

On 13 Oct 2003 at 10:01, Raoul Gough wrote:

> > Thoughts on the below? Is it worth you integrating similar 
> > functionality and thus all other bpl users can use it? Or is this
> > too esoteric and/or demanding to warrant inclusion?
> [snip]
> 
> I can't really comment on this, because I don't understand what the
> code is supposed to do. Can you explain the motivation for it?

The motivation is with a single call to wrap C arrays. Let me give 
you an example:

I have a class FXObjectList which is a bespoke container for 
FXObject's. Among the many fun things it does which normal containers 
would not it also returns the container's contents as a C array and 
provides another method returning the length. Let's call them 
FXObject *getData() and int getDataLen().

Now when wrapping FXObjectList I already have FXObject wrapped - it 
does it's own thing and there's no problem. Just FXObjectList. Before 
I could not wrap FXObjectList without lots of custom code whereas 
with code like I previously posted, it becomes as simple as:

boost::python::class_<FXObjectList, 
boost::noncopyable>("FXObjectList")
        .def("getData", MakeCArray(&FXObjectList::getData, 
&FXObjectList::getDataLen))

And bam!, in one fell swoop the problem is solved.

Another problem I have is that the library I am wrapping provides 
static const indexed lists of constant strings (providing stuff like 
DND target names and MIME types). It's very hard to provide these to 
python code but again with the above, bam! and the problem is solved.

Lastly I have some code which unfortunately returns a pointer to a 
single value just so it can indicate "value is invalid" by returning 
a null pointer. In this situation a MakeCArray(&function, 1) means 
once again bam!, and the problem is solved.

> I have the feeling that you may be reinventing one or two wheels as
> well - e.g. have you considered using std::vector or boost::array, and
> what about type_traits?

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.

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

> > static void *carray;
> > ...
> > carray=(void *) new CArray<getArrayFn, getLenFn>(a, b);
> 
> This look pretty suspect to me - what's going on here?

More temporary code bootstrapping in static data. The actual 
implementation will use a generic functor class I'm writing to store 
the function pointers in a global list which is hash-indexed.

As I previously mentioned, it was a proof of concept.

Now I've explained, your thoughts on whether it would be of use to 
others?

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/20031013/6c012ede/attachment.pgp>