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

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

> May we switch to the mailing list? There a lot of advantages to use it.

Sure I just dropped off the mailing list so there wouldn't be so much noise
for everyone else.

> The important question is: how "pythonic" your interface should be?

It needs to be quite pythonic, the eventual users aren't programmers by
trade and only have exposure to python, no C or C++ abilities, I really
can't count on them being careful at all.
I'd also like keep it all within the library, where there have to be
wrappers I'd rather they were not visible to the end users.

>     void getName(char *buff, int len){
>         strncpy(buff, "bob", len);
>     }
> Hmm. In this case we can create new function transformation
> Another solution is to generate wrapper for such functions and to expose
it.

The best wrapper option I can think of for this is:
static boost::python::object getName(const Bob& bob, int len){
    char buf[len];
    bob.getName(buf, len);
    std::string hw2(buf);
    return bp::object( hw2 );
}
And then I guess I do this stuff
http://language-binding.net/pyplusplus/documentation/how_to/how_to.html in
py++ which all seems straight forward, unfortunately I can't test it until I
get to work tomorrow.
I'm not sure if this would be useful enough for other people to justify
turning it into a transform.

>> The planet example seems to work fine (you suggested in another mail that
it
>> might).
> Good

Sorry, my mistake I haven't actually tested the planet example, what I have
tested is reading a char array, and that works.
However when the the char array contains a nul terminated string the
interface is somewhat ugly so I'm considering wrapping those, but that's a
problem for later.
I will check the planet example in the morning but I suspect at this stage
it's just not being exported at all, I know for sure that char* variables
aren't showing up at all in the generated cpp file.

>     char *fred;
> Consider my advice about ctypes.
> I can patch Py++ today, so instead of exposing the variable it will
> expose the variable address:

Thank you but I think I'd rather avoid that.
I think can see now how I could produce and tie in get_fred and set_fred
functions and how not to leak memory while doing it, I will give that a go
tomorrow and we'll see how it works out.
What I would like to do that I can't currently see a way of achieving is to
wrap those get and set functions together into something that looks like a
variable so on the python side instead of going
bob.set_fred("hello")
print bob.get_fred()
I can use it like this instead
bob.fred="hello"
print bob.fred
This is a nice to have as it means I don't have to deviate as much from the
C++ api and once this is all going I'm going to have to document everywhere
where I deviate from that api.

>> I haven't tested the loadFile example yet and I consider it low priority.
> I guess "modify_type" function transformation could be used. It is a
little bit ugly but it will work

It may already be working, like I said I haven't tried it yet, however it is
showing up in the generated cpp file so maybe it's all good.

On Wed, Jul 9, 2008 at 7:01 PM, Roman Yakovenko <rom...@gm...>
wrote:

> On Wed, Jul 9, 2008 at 10:43 AM, Gordon Wrigley
> <gor...@gm...> wrote:
> > Ok, the disclaimers again, I'm not an expert at either C++ or Python but
> I
> > can get by in both, I don't generally use windows and I haven't done any
> > development for or on windows in years and I've never used boost or msvc
> > before.
>
> May we switch to the mailing list? There a lot of advantages to use it.
>
> > My work has recently acquired a moderately large and expensive piece of
> test
> > equipment. This device has a bunch of windows dlls with C++ headers for
> > developing automation tools. These headers total several thousand lines.
> > I've been given the job of making it work from Python which is our
> > automation language of choice. I got the job because I have an
> established
> > history of being able to slove problems.
> >
> > Currently I have a py++ script that gets most of the stuff exported but
> it's
> > hard to say how much is exported correctly. Currently the script produces
> > ~170 lines of warnings and I understand them all (this is a big step up
> from
> > yesterday). I've gotten the bjam stuff sorted and I can compile link all
> the
> > various dlls (it also uses the matlab common runtime). Then from the
> python
> > console I can import the lib (that was a big step all the dll's have to
> be
> > in line for that to work) run the initilization stuff and connect to the
> > device, or at least I appear to connect I haven't been able to do
> anything
> > useful with it yet.
>
> I understand your warnings and lack of confidence. I tried to build Py++ in
> a
> such way, that if it exports thing they work, otherwise there is a warning
> or
> the declaration is not exported.
>
> > Alot of the stuff in the headers is very basic C like, so char*'s instead
> of
> > strings, arrays of pointers, pointer passing etc and very little in the
> way
> > of OO design or C++ style memory management, actually there's very little
> > dynamic memory stuff at all.
> >
> > I realise that to get a lot of it going I will need to do make custom
> > handlers and that's ok, once I have the first couple of those going I
> should
> > be able to figure the rest out quite quickly.
> >
> > As an example of some of the stuff I need, in the following C++ code
> (which
> > should compile and run with a couple of warnings) I need to be able to do
> > all the stuff in the main function from python.
>
> The important question is: how "pythonic" your interface should be?
> I will explain: in almost no time, you can generate code that returns the
> address of the variable, than you can use ctypes built-in module to work
> with
> that variable. Take a look on
> http://python.net/crew/theller/ctypes/reference.html#data-types
> "from_address" function.
>
> Of course your users will have to be very very careful.
>
> You can improve and to create small wrappers around classes in Python
> that checks preconditions.
>
> Another approach is to expose "Pythonic" API, but it has its price and
> this is not cheep. I suggest you to go
> with the first one.
>
> > #include <iostream>
> >
> > class Bob{
> > public:
> >     char *fred;
> >     char *planet;
> >     double image[10];
> >     double *data[2];
> >
> >     Bob(){
> >         planet="Naboo";
> >
> >         for(int i=0; i<10; i++) image[i]=i;
> >
> >         data[0] = new double[5];
> >         data[1] = new double[5];
> >         for(int i=0; i<5; i++){
> >             data[0][i] = 5-i;
> >             data[1][i] = i+5;
> >         }
> >     }
> >
> >     void getName(char *buff, int len){
> >         strncpy(buff, "bob", len);
> >     }
> >
> >     int loadFile(char *name){
> >         // do stuff
> >         return 0;
> >     }
> > };
> >
> > int main(int argc, char **argv){
> >     Bob *bob = new Bob();
> >     std::cout << "bob->planet = " << bob->planet << std::endl;
> >
> >     bob->fred = "ABC";
> >     std::cout << "bob->fred = " << bob->fred << std::endl;
> >
> >     char buff[10];
> >     bob->getName(buff, 10);
> >     std::cout << "buff = " << buff << std::endl;
> >
> >     std::cout << "bob->image[7] = " << bob->image[7] << std::endl;
> >
> >     std::cout << "bob->data[1][2] = " << bob->data[1][2] << std::endl;
> >
> >     std::cout << "bob->loadFile = " << bob->loadFile("data.dat") <<
> > std::endl;
> > }
> >
> > Getting the getName example above going is probably my most pressing need
> as
> > I need that to get version and status info off the device in order to
> verify
> > that I do actually have a valid connection.
>
> Hmm. In this case we can create new function transformation
> (
> http://language-binding.net/pyplusplus/documentation/functions/transformation/transformation.html
> )
>
> It should not be too difficult.
>
> Another solution is to generate wrapper for such functions and to expose
> it.
>
> > The planet example seems to work fine (you suggested in another mail that
> it
> > might).
>
> Good
>
> > Once I get the fred example going I can probably figure out the the image
> > and data ones.
>
> Consider my advice about ctypes.
>
> I can patch Py++ today, so instead of exposing the variable it will
> expose the variable address:
>
> mb = module_builder_t( ... )
> mb.var( 'fred' ).expose_address = True
>
> Better name for property is welcome
>
> > I haven't tested the loadFile example yet and I consider it low priority.
>
> I guess "modify_type" function transformation could be used. It is a
> little bit ugly
> but it will work
>
> > Also I very much appreciate the help you have been giving me, thank you.
>
> My pleasure.
>
> --
> Roman Yakovenko
> C++ Python language binding
> http://www.language-binding.net/
>