Re: [boost] boost::python: implementation of static data members

From: David Abrahams (david.abrahams_at_[hidden])
Date: 2001-12-05 07:47:07

----- Original Message -----
From: "Scott Snyder" <snyder_at_[hidden]>

> >>>>> "David" == David Abrahams <david.abrahams_at_[hidden]> writes:
>     David> Thanks very much for your patches. At first glance they
>     David> look good. There are a few things that need to be done to
>     David> make them complete patches for the library:
>
>     David> 1. Patches for libs/python/test/comprehensive.cpp and
>     David> libs/python/test/comprehensive.py to test the new features
>     David> 2. Patches for the Boost.Python documentation to advertise
>     David> them ;-)
>
> Ok, thanks for looking at this.  I'll work on doing that as soon
> as i get a chance (sometime this week, i hope).
>
> At a quick glance, it looks like the html files themselves are the master
> files for the documentation (i.e, not derived from something more
structured).
> Correct?

Yes. I've been thinking about alternatives. Do you have a suggestion?

>     David> Also, it looks like the static member accessor patch should
>     David> really also patch the getattr/setattr capabilities of the
>     David> object's extension_class, don't you think?
>
> Likely so; i'll look at it.
>
> To back up a little, i've been playing with trying to generate the
> boost wrapper code (mostly) automatically, as a result of parsing
> the C++ headers.  One difficultly i've been running into that doesn't
> seem to have a good solution has to do with overload resolution: in some
> cases, the algorithm used by boost gets a different result than C++ would.
> For example, in
>
>   struct A {};
>   struct B : public A {};
>
>   void foo (const A&);
>   void foo (const B&);
>
>   foo (B())
>
> boost ends up calling the first foo(), while C++ would call the second.
> To some extent, this can be worked around by ensuring that the methods
> are declared to boost in the proper order --- but this isn't completely

Bingo. If you wrap functions taking derived classes first, you'll get the
expected behavior. Ullrich Koethe has also been talking about a way to be
more principled about this.

> satisfactory, first, because it doesn't scale well for large interfaces,
> and second, because it doesn't work in general (for example, in the case
> where you have two types, each of which is convertable to the other).
> I don't see any way to solve this in general, though, without major
> changes in how the overload resolution works.

I'm open to that... eventually. Right now I'm working on standards
conformance and cross-module inheritance support.

Thanks for your contributions,
Dave