Re: [pygccxml-development] problem with an array of pointers

[Gordon W. <gor...@gm...>]

OK, that seems to make some sense, but leads to a few lil feature requests.

First the py++ code on that page is overly verbose, it would be nice if this
could be handled in one line. So for this C++ code:

class tom
{
public:
  double *data;
  double dataLen;

you might have something like:

mb.class_( "tom" ).variable( "data" ).size("tom.dataLen")

I realise it's probably not going to be quite that simple, I'm just trying
to convey the direction of the idea. Also if you had a standard policy of
always having a xLen variable for every x pointer variable (or xLen function
for every function returning a pointer) then it'd be nice to be able to
capture that in a single line.

And of course this would all have to be extended somehow to work with my
array of pointers example and the documentations width*heigh example.

Also that warning that py++ should give when it runs into one of these
should include an example of the sort of line required to fix it.

:)

Gordon.

On Mon, Jul 7, 2008 at 6:51 PM, Roman Yakovenko <rom...@gm...>
wrote:

> On Mon, Jul 7, 2008 at 10:28 AM, Gordon Wrigley
> <gor...@gm...> wrote:
> > Disclaimer: I have no idea what I'm doing and C++ is not one of my strong
> > skills. I'm having a problem with py++, boost, msvc and a third party
> > library I need to bridge to python. I would greatly appreciate any help I
> > can get with this.
>
> :-)
>
> > I don't have the various version information handy but I downloaded all
> of
> > the boost/py++/msvc stuff from the relevant websites last week. After I
> > installed everything I made it compile and run the quick start example
> > correctly.
> >
> > I ran the library header through the py++ gui, grabbed the py++ code that
> > generated, put it in a .py file, ran that and then copied the resulting
> > files into the quick start example.
> >
> > The header for the library includes this snippet (details obscured to
> > protect the guilty):
> >
> > class bob
> > {
> > public:
> >     double      *fred[4];
>
> This is a bug in Py++.
>
> The code generated for "double* fred[4]" caused the compilation error.
> It is not possible to generate code for "fred" without knowing
> additional details. In this case Py++ has to exclude this variable
> from being exposed and give some warning.
>
> Now, how can you improve the situation:
> * exclude variable by your own
> * take a look on "return_range" (
>
> http://language-binding.net/pyplusplus/documentation/functions/call_policies.html#return-range
> ) call policies.
>
> HTH
>
> --
> Roman Yakovenko
> C++ Python language binding
> http://www.language-binding.net/
>