[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:

>All:
>
>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
>declarations.
>  
>
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.

>Thanks,
>
>Roman Sulzhyk 
>  
>
Regards,
Nicodemus.






More information about the Cplusplus-sig mailing list