Boost logo

Boost :

From: David Abrahams (david.abrahams_at_[hidden])
Date: 2001-10-22 18:14:32


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?


  David Abrahams, C++ library designer for hire

        C++ Booster (
          email: david.abrahams_at_[hidden]

Boost list run by bdawes at, gregod at, cpdaniel at, john at