Re: [boost] py_cpp: bugs in the docs, feature requests...

From: David Abrahams (abrahams_at_[hidden])
Date: 2000-10-31 08:49:27

----- Original Message -----
From: "Prabhu Ramachandran" <prabhu_at_[hidden]>

> hi,
>
> I've been trying out py_cpp and have manged to get the hang of it,
> somewhat.  Here are some issues...
>
>     (1) There are some bugs in the documentation.
>
>     In the section titled overridable virtual functions, the
>     default function definition is given as follows:
>
>     const char* default_get() const
> { return this->hello::world::get(); }
>
>     This does not _compile_ under gcc.  I looked at your extclass_demo
>     and figured that the following works.
>
>     static const char* default_get (hello::world *self)
> { return self->hello::world::get (); }
>
>     This works fine.  I'd appreciate a change in the docs that reflect
>     this.  It was a pain assuming that the docs were right and looking
>     for other non-existent errors.

I appreciate that. Thanks for tracking this bug down. I think this is an old
usage that used to be supported but is not any longer and hasn't been tested
recently. Consider it fixed.

>     Also, if it isnt too hard to
>     explain, I'd like to know why this works and why the first one
>     doesnt.

Python deals with member functions by passing an explicit "self" parameter
as the first argument. Without the "static", the function is a member
function of world_callback, so the implicit first argument is a struct
world_callback*... but only struct world has been exposed to Python, so the
conversion from PyObject* to world_callback* is missing, causing the error.
I could do something to make the other usage work, but I'm not sure it's
worth it. My feeling is that one way to do it is enough, (provided that it's
correctly documented, of course ;-))

>     (2) Given a class library, it is normal for a useful concrete
>     class to have a large inheritance.  Currently, with py_cpp, if I
>     have class_B derived from class_A (in the C++ code) and only
>     expose the methods new to class_B in the wrapper code, I cannot
>     call inherited methods for class_B under python unless I re-expose
>     them for class_B.  This implies that for a large inheritance, I'd
>     have to look at every base class and pull out all the inherited
>     functions and wrap them all.  This is rather painful.  Is there a
>     way out of this?  Or is this impossible to implement?  Or am I
>     missing something.

You're missing the as-yet-undocumented construct
"class_B.declare_base(class_A)" which was implemented by Ullrich Koethe. I
am going to make a new release today that includes documentation for this
feature.

Regards,
Dave