A gentle critque..

[Ben Cooley]

>Yes, we're in agreement insofar as we both think it would be good if it were
>easier to use legacy C and C++ code with new D code.  I think the majority of
>readers of this list would agree there's nothing wrong with that.  They might
>prioritize it differently, but I think most everyone here can agree that if a
>magic wand could make C++ callable from D then it should be done.  But seeing
>Walter's Giant List of all the interoperability issues pretty much clenches it
>for me that making D work _directly_ with C/C++ is just a non-starter.  Not
>unless Google "buys" D tomorrow and throws 20 full time engineers on it.  On the
>other hand, SWIG, or SWIG-like, wrapping of C/C++ for consumption by D is a much
>more feasible, realistic goal.  SWIG makes the easy stuff easy (automatic, just
>%include "header.h") and the hard stuff doable (with manual annotations), but it
>doesn't magically make the impossible possible (like porting the STL to Python).
>
>Forgive me if I'm misunderstanding you, but your talk of accessing vtables and
>such from D sounds like you're still thinking of making D understand C++
>binaries.  I just don't think that's practical given the current D development
>situation.  But I think it would only take one or two determined souls to revive
>the SWIG approach and wrangle it into something useful.

The majority of issues Walter listed simply don't apply to the strategy I'm
going to try.  There are no issues with parsing because that task is handled
using an external tool (GCC-XML).  There are no issues with specific C++
language details because any construct outside of cpp vtable calls or member
access are simply punted to wrappers in the auto generated Cpp file.

As for swig, the parsing of headers in SWIG is not really adequate IMO.  It
takes shortcuts which tend to break.  In any case, since GCC-XML exists, and it
was actually written specifically to produce the precise sort of reflection info
you need here, why bother with an imprecise parser like swig?  They're using
GCC-XML for the current C++ reflection library at cern and I've personally
parsed some of our own code here, and it works fine.  Of course Elsa also works
on our code here after running it through the pre-processor.. which is quite
remarkable given the extensive amount of template programming we use, but it
doesn't parse some of the MS specific stuff which GCC-XML handles.

In any case, I really think you can do better than wrapping. If you can get an
accurate vtable layout, macros, method list and params, and class/struct layout
for standard classes, you pretty much have the information that you need to
access members and call vtable methods.

For the rest: templates, complex macros, exception handling, rtti, etc.. yes,
I'm saying it would use inline cpp {} and generate "wrapper code" for these the
same way swig does.. and call this wrapper code via extern C function calls to
an externally compiled and linked Cpp file.