An even more modest proposal...

[Ben Cooley]

In article <Pine.LNX.4.64.0605152309500.2422 at bellevue.puremagic.com>, Brad
Roberts says...
>
>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

Well okay.. if that's what it takes.