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

[David Abrahams]

"Niall Douglas" <s_sourceforge at nedprod.com> writes:

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

The complexity I was talking about would only show up in the
implementation.  These are implementation details.

<snip>

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

I'd love to commence such an effort.  It seems fairly obvious to me
that it'd require funding, though.

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

Actually it's the opposite.  Those areas where GCC restricts what you
can do but MSVC does not are not open to interpretation: GCC gets it
right and MSVC gets it wrong.  In fact, in some of the areas where
different interpretations of the standard are possible (e.g. Koenig
Lookup), GCC is IMO far too liberal, which breaks otherwise correct
code.

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