• Ben Cooley <Ben_member pathlink.com> May 15 2006
• Brad Roberts <braddr puremagic.com> May 15 2006
• Ben Cooley <Ben_member pathlink.com> May 15 2006
• Brad Roberts <braddr puremagic.com> May 15 2006
• Ben Cooley <Ben_member pathlink.com> May 15 2006
• Thomas Kuehne <thomas-dloop kuehne.cn> May 15 2006
• James Dunne <james.jdunne gmail.com> May 15 2006
• Kyle Furlong <kylefurlong gmail.com> May 16 2006

Ben Cooley <Ben_member pathlink.com> writes:

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.

Brad Roberts <braddr puremagic.com> writes:

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

Ben Cooley <Ben_member pathlink.com> writes:

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?

Brad Roberts <braddr puremagic.com> writes:

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

Ben Cooley <Ben_member pathlink.com> writes:

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 <thomas-dloop kuehne.cn> writes:

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

James Dunne <james.jdunne gmail.com> writes:

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

Kyle Furlong <kylefurlong gmail.com> writes:

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