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

[Nicodemus]

Ralf W. Grosse-Kunstleve wrote:

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

Hi Ralf,

It doesn't, and I believe it would be very hard for it to do it, because 
normally the comments are discarded during the syntax check, so the 
grammar would have to change to support that... but we should ask Brad 
King to know for sure.

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

Seems like a good scenario... the compile times are really a nuisance, 
and a step in the direction of reducing them would be great. In my 
company it is not that big of a deal, because the C++ code uses a lot of 
template metaprogramming also, so that it takes about 70 minutes to 
compile in my dual Pentium II 800 box at work, so the 15 minutes needed 
by the bindings are shadowed by the time taken to build the library. 8)
Thankfully I wrote a system that distributes the files across de 
network, allowing all of our computers to compile the files together. 
But I digress...

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

Nah, I don't think so. ;)