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.

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

In article <Pine.LNX.4.64.0605152210020.2422@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?

On Tue, 16 May 2006, Ben Cooley wrote:

> In article <Pine.LNX.4.64.0605152210020.2422@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

Brad Roberts schrieb am 2006-05-16:
> 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'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.

Ben, in case you don't have the resources I'd be interested to solve Brad's challenge. As the scale of problems is definitely beyond spare time development, this would have to be paid development.

Thomas

In article <Pine.LNX.4.64.0605152309500.2422@bellevue.puremagic.com>, Brad Roberts says...
>
>On Tue, 16 May 2006, Ben Cooley wrote:
>
>> In article <Pine.LNX.4.64.0605152210020.2422@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.

Thomas Kuehne wrote:
> -----BEGIN PGP SIGNED MESSAGE-----
> Hash: SHA1
> 
> Brad Roberts schrieb am 2006-05-16:
> 
>>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'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.
> 
> 
> Ben, in case you don't have the resources I'd be interested to solve
> Brad's challenge. As the scale of problems is definitely beyond spare time
> development, this would have to be paid development.
> 
> Thomas
> 
> 
> -----BEGIN PGP SIGNATURE-----
> 
> iD8DBQFEaXzq3w+/yD4P9tIRAln9AJ9HtoUMjv2WCS/MtuUnIs1k/u/PWwCgke9P
> cig+vhtMYbylNxJHRqoxa3Q=
> =hPeN
> -----END PGP SIGNATURE-----

Nothing is beyond the scale of spare time development :)

-- 
Regards,
James Dunne

James Dunne wrote:
> Thomas Kuehne wrote:
>> -----BEGIN PGP SIGNED MESSAGE-----
>> Hash: SHA1
>>
>> Brad Roberts schrieb am 2006-05-16:
>>
>>> 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'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.
>>
>>
>> Ben, in case you don't have the resources I'd be interested to solve
>> Brad's challenge. As the scale of problems is definitely beyond spare time
>> development, this would have to be paid development.
>>
>> Thomas
>>
>>
>> -----BEGIN PGP SIGNATURE-----
>>
>> iD8DBQFEaXzq3w+/yD4P9tIRAln9AJ9HtoUMjv2WCS/MtuUnIs1k/u/PWwCgke9P
>> cig+vhtMYbylNxJHRqoxa3Q=
>> =hPeN
>> -----END PGP SIGNATURE-----
> 
> Nothing is beyond the scale of spare time development :)
> 

It just depends how long such a project is willing to sit in the queue! :-D

-- 
Kyle Furlong // Physics Undergrad, UCSB

"D is going wherever the D community wants it to go." - Walter Bright