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

[David Abrahams]

"Ralf W. Grosse-Kunstleve" <rwgk at yahoo.com> writes:

> --- 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 :)

Well, I ran into problems implementing it, but I learned a lot about
what's really needed in the process.

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

Yes, that one.

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

Not so; you're just thinking of the wrong meta-programming tools ;->

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

That's meta-programming, too ;->

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

But Pyste doesn't do it that way.

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

These aren't so drastic; I've been saying things like this for
several months.  However, you might ask yourself "why not just use
SWIG?"

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

Actually, I don't think it will help with most of the issues I raised.
These are fundamental design problems that will arise no matter how
you generate the code.

> 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? :)

-- 
Dave Abrahams
Boost Consulting
www.boost-consulting.com