[C++-sig] Re: C arrays solution
s_sourceforge at nedprod.com
Mon Oct 13 23:22:38 CEST 2003
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?
> 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:
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
> 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
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Size: 208 bytes
Desc: not available
More information about the Cplusplus-sig