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

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

on http://language-binding.net/pyplusplus/documentation/how_to/how_to.html I
believe the following code:

registration_code = 'def( "get_size", &%s::get_size )' %
window.wrapper_alias

mb = module_builder_t( ... )
window = mb.class_( "window_t" )
window.member_function( "get_size" ).exclude()
window.add_wrapper_code( wrapper_code )
window.registration_code( registration_code )

should instead read

mb = module_builder_t( ... )
window = mb.class_( "window_t" )
window.member_function( "get_size" ).exclude()
window.add_wrapper_code( wrapper_code )
registration_code = 'def( "get_size", &%s::get_size )' %
window.wrapper_alias
window.add_registration_code( registration_code )

and I now have the getName example working


On Wed, Jul 9, 2008 at 9:49 PM, Gordon Wrigley <gor...@gm...>
wrote:

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