Re: [boost] Re: python wrapping question - non standard constructor/destructor

From: Ullrich Koethe (u.koethe_at_[hidden])
Date: 2001-10-22 19:22:40

David Abrahams wrote:
> 
> Ulli,
> 
> I'm glad to hear you're making progress on Boost.Python. I'll be starting a
> short support contract for Boost Python at the end of the week, so there's a
> good chance of more progress in the near future. Do you have other
> outstanding changes which you think I should integrate?
> 

Well, there is a small bug in the overload resolution code for
operators. Suppose we have two classes A and B, and want to export all
possible combinations of '*'

def()'ed in A:
    A * A
    A * B

def()'ed in B:
    B * B
    B * A

Then, B * A is never found during lookup. I have a simple fix for this.

> >
> > PS: So far, I'm very pleased with Boost.Python. I have begun exporting
> > my VIGRA library, and I haven't had any major problems. One weak point,
> > however, is the implementation of customized 'to_python()/from_python()'
> > functions. For eample, I want to arrange for a float sequence of length
> > 3 to be silently accpeted wherever an RGBValue object is expected. Have
> > you any ideas here?
> 
> Why not just add an overload which takes a python::ref, and handle the
> type/concept checking yourself within the overload?
> 

Perhaps you are right. But it seems to me that from_python() would be
the right place for this to avoid redundancy.

I've actually implemented a partial solution: I've refactored a new base
class 'python_extension_class_converters_base' (which contains function
implementations) out of 'python_extension_class_converters', and the
latter only defines the friend functions by trivially forwarding the
work to the base class' members. This makes it relatively easy to
explicitly instantiate 'python_extension_class_converters' for a
particular class. However, if I don't want to define all converter
variants, this is quite inconvenient because corresponding changes have
to be made for cross_module support.

A principled solution would be to allow for switching on and off the
instantiation of converter functions. This might be possible by means of
a template technique similar to the one used for operators. Something
like

 template <..., int ConverterFlags = all_converters>
 class python_extension_class_converters
 : python_define_converter_value<..., ConverterFlags & converter_value>,
   python_define_converter_ptr<..., ConverterFlags & converter_ptr>,
   ...

where python_define_converter_...<..., 0>  would do nothing. If a
non-default converter is needed, the default is left out in the flag,
and the replacement explicitly defined. But I'm afraid this technique
will lead to even more code bloat and longer compile times (apart from
not working directly on MSVC). There must be a simpler way!

Another unsolved problem seems to be the base class conversion for smart
pointers. Or am I missing something here (or made a stupid mistake)?

Regards
Ulli
-- 
 ________________________________________________________________
|                                                                |
| Ullrich Koethe  Universität Hamburg / University of Hamburg    |
|                 FB Informatik / Dept. of Computer Science      |
|                 AB Kognitive Systeme / Cognitive Systems Group |
|                                                                |
| Phone: [phone]                Vogt-Koelln-Str. 30 |
| Fax:   [phone]                D - 22527 Hamburg   |
| Email: u.koethe_at_[hidden]               Germany             |
|        koethe_at_[hidden]                        |
| WWW:   http://kogs-www.informatik.uni-hamburg.de/~koethe/      |
|________________________________________________________________|