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

From: Scott Snyder (snyder_at_[hidden])
Date: 2001-12-05 01:27:25

>>>>> "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?

    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
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.

thanks,
sss