|
Boost : |
From: David Abrahams (david.abrahams_at_[hidden])
Date: 2001-10-22 18:14:32
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?
----- Original Message -----
From: "Ullrich Koethe" <u.koethe_at_[hidden]>
> Hi Drew and Dave,
>
> I'm working on Boost.Python again, and have found a similar problem. In
> the constructor case, I've added code to my local version of
> Boost.Python which allows an arbitrary factory function to be used as a
> Python constructor by exporting it under the name "__init__". Standard
> overload resolution applies, and both real constructors and factory
> functions can be used for the same class. It works for the cases I need,
> but I haven't tested it for all possible usages (especially in the
> context of complicated Python inheritance hierarchies with multiple C++
> base classes).
>
> I haven't looked into destructors, but something similar could probably
> be done here. If you are interested, I can check the code into a branch.
>
> Best regards
> Ulli
>
> 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?
-Dave
===================================================
David Abrahams, C++ library designer for hire
resume: http://users.rcn.com/abrahams/resume.html
C++ Booster (http://www.boost.org)
email: david.abrahams_at_[hidden]
===================================================
Boost list run by bdawes at acm.org, gregod at cs.rpi.edu, cpdaniel at pacbell.net, john at johnmaddock.co.uk