[C++-sig] Boost.Python: few thoughts and questions...

Nicodemus nicodemus at globalite.com.br
Fri Jun 13 23:00:07 CEST 2003

Roman Sulzhyk wrote:

>First, want to say thank you for terrific work on boost.python - first
>time I've touched it in a few years and am very impressed by version
>2.0 and especially pyste. 
Thanks a lot!

>1. Virtual functions
>The automatic overloading of virtual functions is great, however I see
>situations where it would be nice to be able to disable it. For
>example,  I'm trying to expose a derived class which has some virtual
>members inherited from its sub-classes, yet I have no intention to
>overload them in python and hence would like to save on the wrapper
>code generation.

Certainly, that's easy to add... I was aware that this need might come up.

>Also, when I'm exposing a class, I think it would be nice to expose all
>of the virtual methods inherited from base classes, even if they're not
>explicitly overloaded in the class itself - do you think that would be
>useful functionality to add?
I don't know... why don't you export the base class itself? That way the 
methods will be avaiable in the derived class thanks to Boost.Python.

>2. Virtual functions declaring exceptions
>Basically, a simple construct like this
>struct foo {};
>struct World
>  virtual const std::string &hello() throw (foo) { return msg; }
>causes pyste generated code to choke, because the exception declaration
>of the wrapper function is looser than the original one (gcc 3.2)
Yes, that issue has been brought up in the past here in the list, but 
not until recently Brad King has added support for it in GCCXML. As soon 
as I can I will implement this.

>3. Specifying the set_policy() for virtual functions
>It appears that the policy setting is ignored for virtual function
That's a bug. I fix it as soon as I can.

>Anyway, I've started playing around with it and worked around some of
>these issues, updating pyste to take into account policy for virtual
>functions. For the throw specifier problem, it appears that there is no
>easy solution, as GCCXML does not generate throw specifier data as far
>as I can tell, requiring changes to gccxml for full solution.
>I've also added an 'unvirtual' function to pyste, kind of like
>'exclude', which allows a user to specify that a function should be
>treated like a regular rather than virtual method when creating a
>reflection - that works around the 'looser throw specifier' problem
>I've mentioned.
>Anyway, would like to sync up on what you think about these issues and
>whether it's worthwhile to package the changes and submit a patch.
Certainly, that would be great. Thanks a lot!

Unfortunately, my hard drive went dead on me and I am at a temporary 
machine, so I don't know if I will be able to make any changes in Pyste 
for now. I should be back up only next week. Sorry about that.

>Roman Sulzhyk 

More information about the Cplusplus-sig mailing list