[C++-sig] [Implementation] Calling wrapped functions, converters, policies

[Ralf W. Grosse-Kunstleve]

--- David Abrahams <dave at boost-consulting.com> wrote:
>    Example 2: In implementing injected constructors I want to strip
>    the incoming "self" argument before calling the inner factory
>    function, then install the result in the self object.

I am thrilled by the prospect of having this feature :)

>    I'm leaning towards a. but I'm really not sure which one is best
>    and would appreciate comments.

To repeat my mantra: I very much prefer the simpler approach even if it incurs
a runtime penalty. If crossing the language boundary is the rate-limiting step
the design is fundamentally wrong anyway.

>    For example, people have asked that they be able to pass a Python
>    list where a std::vector<T>& argument is expected, modify the
>    vector, and have the Python list automatically updated when the
>    function call returns.  Because this converter requires a
>    std::vector<T> lvalue, it doesn't contain storage for the vector
>    whose lifetime needs to span the length of the call.  Furthermore,
>    if the call completes successfully, the source list must be updated
>    to reflect the new contents of the vector.

Ah, my "most wanted" feature.

> Comments?

Yes. There is another most wanted feature on my list: automatic integration of
documentation embedded in C++ code. I.e. I'd like to see my Doxygen
documentation appear merged with the Python documentation. It seems to me that
no amount of meta-programming wizardry will be able to do this. My current
state of mind is that gcc-xml/Pyste could potentially provide a solution.
Bruno, does gcc-xml preserve the comment blocks in C++ code? If not, could it
be made to?

Jumping ahead:

1. I find myself quite often adding a thin Python layer on top of the raw
Boost.Python bindings, for example to get keyword support without increasing
compile times and object code size, or to inject additional methods.

2. To me the popularity of Pyste shows that this is the way of the future.

This leads me to drastic suggestions:

- Treat the entire C++ layer of the Python-based wrapping system as an
implementation detail.

- Let the user direct the wrapping process exclusively via a Pyste-style pure
Python script.

- Simplify the Boost.Python code base by scaling down the amount of work that
is done with meta-programming techniques.

- Always generate an intermediate Python layer with full, automatic keyword
support and a copy of the documentation embedded in the C++ code.

- Use SCons (pure Python again) to control the generation of all intermediate
files and the management of all dependencies.

My suggestions are partially motivated by the belief that some of the problems
outlined in David's original posting will be much easier to deal with in a
framework as outline above. The critical ingredient that makes this possible is
gcc-xml, which provides the tool for analyzing the C++ code to be wrapped "from
outside" instead of "from inside" using compile-time introspection facilities
that were clearly not designed for this purpose.

Ralf

P.S.: Is this the same person that tried to talk Bruno out of writing Pyste? :)


__________________________________
Do you Yahoo!?
Yahoo! SiteBuilder - Free, easy-to-use web site design software
http://sitebuilder.yahoo.com