An even more modest proposal...

[Brad Roberts]

On Tue, 16 May 2006, Ben Cooley wrote:

> In article <Pine.LNX.4.64.0605152210020.2422 at bellevue.puremagic.com>, Brad
> Roberts says...
> >
> >On Tue, 16 May 2006, Ben Cooley wrote:
> >
> >> Allow D to import a GCC-XML or an alternative xml file with the class hierarchy,
> >> structure layout, members, methods, and macros defined in a c or cpp header, and
> >> be able to access members, call non-inlined methods, or auto-generate a .cpp
> >> file with cpp code or functions for inline methods calls or template
> >> instantiations in D.
> >> 
> >> This would eliminate the need for D to be responsible for parsing Cpp, and
> >> directly provide the D with the information it needed to interoperate with
> >> existing C or Cpp libraries and code.  The responsibility of generating that
> >> file would be from an externally supported Cpp parser like GCC XML, Elsa, or
> >> Swig.
> >> 
> >> D = Cpp/CLI ....  XML = CLI.  That would be an apples to apples comparison.
> >> 
> >> How you generate that XML file is your problem.
> >
> >I invite you to do it and show us that it's as easy and possible as you 
> >claim.  The problems are enormously technically complex, as quite a few 
> >people have said several times already.  It's incredibly unlikely that 
> >anyone is going to do this just because you want it done.
> >
> >I could repeat a number of the already covered topics, but it's obvious 
> >you aren't willing to accept them.  Please, prove everyone wrong and get 
> >it working.
> >
> >I'll even suggest a relatively low barrier to entry:  Show that you can 
> >call a c++ class (no inheritance involved) with an api that takes a 
> >std::string and throws that string back to the caller as an exception.  
> >The caller has to be able to catch that std::string.
> >
> >Later,
> >Brad
> 
> Sure...
> 
> CppType("std::string") str = NewCppObject("std::string(\"A string\"");
> CppType("std::string") ret;
> 
> // Inline cpp code which is placed in the .cpp file generated for this file
> cpp {
> try {
> throwFunction(%%str);   
> }
> catch (std::string exstr)
> {
> %%ret = exstr;
> }  
> } 
> 
> return CppCallMethod("ret.c_str()"); 
> 
> -----------------
> 
> The intrinsics compile directly to D code.  The inline cpp code is exported to
> the associated generated .cpp file the same way that the calls to other inline
> cpp code are:
> 
> extern "C" {
> void __somefunction_inlinecpp(std::string& str, std::string& ret)
> {
> try {
> throwFunction(str);   
> }
> catch (std::string exstr)
> {
> ret = exstr;
> }  
> }
> }
> 
> Since D can directly link with C, you have yourself a pretty decent way of
> easily inlining Cpp code by simply generating a C function for each cpp inline.
> 
> Now... was that really all that complicated?

I'll give you the benefit of the doubt and that you genuinely 
misunderstood what I was saying.  Let me rephrase:

Anyone can type out some pseudo code and say tada.  That's not useful.  
Make it work, show that it actually can be done.  Produce the patches to 
gdc that accomplish what you suggest.

Later,
Brad