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

[Niall Douglas]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

On 18 Sep 2003 at 11:01, Ralf W. Grosse-Kunstleve wrote:

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

I would go further and say that truly obscene implementation is 
permitted if the end-user's life is made easier. This is the point of 
a library IMHO.

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

Yes I believe it does. And I strongly second this idea though I'd 
suggest the python documentation could optionally be a http URL to 
the relevent doxygen docs. No point making the python files huge if 
they don't need to be.

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

Agreed. Me personally, and I think most users of Boost.Python will 
agree, would feel that they don't care how Boost.Python works. They 
simply want to feed something their existing C++ source and a python 
loadable DLL is spat out. The less arsing around with config files 
and boost.python idiosyncracies the better.

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

I'm a great believer in onion style design - layers of functionality 
so if the top layer won't do what you want, you can hack the lower 
layers to force the issue.

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

I'm increasingly using python to manage my project, so this looks 
good.

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

GCC-XML is broken in some areas, but I'm sure its bugs will be fixed 
with time. My only concern is that GCC is overly conservative in its 
interpretation of the C++ standard - code which MSVC permits (and I 
would permit) GCC barfs on.

Lastly, anything to reduce compile times would be a boon. I have a 
dual Athlon 1700, yet to compile a full set of bindings will take 
twenty hours or so. This is unacceptable.

Cheers,
Niall





-----BEGIN PGP SIGNATURE-----
Version: idw's PGP-Frontend 4.9.6.1 / 9-2003 + PGP 8.0.2

iQA/AwUBP2octMEcvDLFGKbPEQLSZgCfRzHT0awZRzUWzeH53397rtqvF7gAn2+l
slloFuqwKdg3yvPoS3NnXOJq
=aDc3
-----END PGP SIGNATURE-----