www.digitalmars.com         C & C++   DMDScript  

D - C++ link capability and D

reply Adam Treat <Adam_member pathlink.com> writes:
Can D achieve C++ link capability by incorporating a general C++ introspection
library? 
 
This is what the overview has to say: 
 
"Link compatibility with
C++. The C++ runtime object model is just too 
complicated - properly supporting
it would essentially imply making D a full 
C++ compiler too." 
 
Well, perhaps
this could be achieved through a C++ introspection engine 
instead.
Alternatively, a gcc frontend for D could take advantage of the C++ 
compiler.
Perhaps some changes would need to be made to the specs, but IMO 
C++ link
compatibility would increase the usefullness of D by orders of 
magnitude.  I
would love to use D to do KDE/Qt programming without the 
necessity of a C++ ->
C -> D binding. 
 
Anyone have similar thoughts or ideas? 
 

style attributes?  I think this was one of the best 

Nov 24 2003
next sibling parent Andy Friesen <andy ikagames.com> writes:
Adam Treat wrote:
 Can D achieve C++ link capability by incorporating a general C++ introspection
 library? 
  
 This is what the overview has to say: 
  
 "Link compatibility with
 C++. The C++ runtime object model is just too 
 complicated - properly supporting
 it would essentially imply making D a full 
 C++ compiler too." 
  
 Well, perhaps
 this could be achieved through a C++ introspection engine 
 instead.
 Alternatively, a gcc frontend for D could take advantage of the C++ 
 compiler.
 Perhaps some changes would need to be made to the specs, but IMO 
 C++ link
 compatibility would increase the usefullness of D by orders of 
 magnitude.  I
 would love to use D to do KDE/Qt programming without the 
 necessity of a C++ ->
 C -> D binding. 
  
 Anyone have similar thoughts or ideas? 
I don't think an introspection engine would be necessary. Just an extern(C++) convention for exported C++ classes. Reference arguments are essentially pointers. STL... well, we'll have to live without that. (most libraries don't expose STL containers anyway) Overloading is just a little bit more mangling. The only thing that's left is namespaces, which is just an extra bit of name mangling. (nobody exports template functions, so we're safe there, right?) Of course, I've never written a compiler, much less a C++ compiler, so maybe I'm overlooking something.

 style attributes?  I think this was one of the best 

What would they be useful for? -- andy
Nov 24 2003
prev sibling parent reply Ilya Minkov <minkov cs.tum.edu> writes:
Adam Treat wrote:
 Can D achieve C++ link capability by incorporating a general C++
 introspection library?
Urgh... Have you ever seen a C++ introspection library? E.g. one written in C++? In general, you cannot introspect C++ from itself or by looking at object code... 'Cmm' can do it, but it is an extended C++ compiler which interleaves storage with type information, which is not even complete enough. And if you had unified access to some introspection information, it would still make use pretty masochistic. Unless you like climbing through dozens of closures at each step. So forget it.
 Perhaps some changes would need to be made to the specs, but IMO C++
 link compatibility would increase the usefullness of D by orders of 
 magnitude.  I
Fairly true. I think some (commercal?) compilers will carry link compatibility as a bonus.
 would love to use D to do KDE/Qt programming without the necessity of
 a C++ -> C -> D binding.
We have a SWIG port now. It generates multiple wrappers which let you use the library naturally, as you do in C++, unlike the introspection method... Maybe we'll have better generator someday. But still, it's the only feasible way.


-eye
Nov 24 2003
next sibling parent reply Adam Treat <Adam_member pathlink.com> writes:
In article <bptodb$28ni$1 digitaldaemon.com>, Ilya Minkov says... 
 Perhaps
some changes would need to be made to the specs, but IMO C++
 link
compatibility would increase the usefullness of D by orders of
 magnitude.
I
 
Fairly true. I think some (commercal?) compilers will carry link
compatibility as a bonus. 
I see that a gcc frontend for D is in the works. Perhaps this can accomplish link compatibility.


or class that can be retrieved and used at runtime via the reflection/introspection engine. Here are a few quick resources: <a href="http://www.ondotnet.com/pub/a/dotnet/excerpt/prog_csharp_ch18/">one</a> and <a href="http://msdn.microsoft.com/library/en-us/csref/html/vclrfIntroductionToAttr butes.asp">two</a>.
Nov 24 2003
parent reply Ilya Minkov <midiclub tiscali.de> writes:
Adam Treat wrote:
`
Fairly true. I think some (commercal?) compilers will carry link
compatibility as a bonus. 
I see that a gcc frontend for D is in the works. Perhaps this can accomplish link compatibility.
Not readily. First, guess who is on the project. As for a few days ago, almost noone but myself. Well, i didn't do much either. But as for now, i must admit that i have too little time to continue right now... but maybe i'll be able to find someone else continuing my work. Second, we have not yet decided which way to go. We can go through C++ output, then it is feasible to try at C++ link compatibility. But if we communicate to back-end directly, than it's not. Because we shall no way hack on the G++ itself... It may also make sense that the free compilers don't support C++ linkage, just to avoid interfering with Walter's possible plans.

 or class that can be retrieved and used at runtime via the 
 reflection/introspection engine.  Here are a few quick resources: <a 
 href="http://www.ondotnet.com/pub/a/dotnet/excerpt/prog_csharp_ch18/">one</a> 
 and <a 
 href="http://msdn.microsoft.com/library/en-us/csref/html/vclrfIntroductionToAttr
butes.asp">two</a>. 
Reflection implies the possibility to change/generate code at run-time, which we cannot do, since we don't want to force everyone to get a compiler just to run a little proggie. :) However, it may be that such things can be supported through "compile-time reflection". Look for OpenC++. Walter promised we are going to have something like that someday. OpenC++ allows you to write classes which extend the compiler, and re-engineer code or introduce new syntactic constructs. -eye
Nov 25 2003
parent davepermen <davepermen_member pathlink.com> writes:
In article <bpvl91$247g$1 digitaldaemon.com>, Ilya Minkov says...
Reflection implies the possibility to change/generate code at run-time, 
which we cannot do, since we don't want to force everyone to get a 
compiler just to run a little proggie. :)

However, it may be that such things can be supported through 
"compile-time reflection". Look for OpenC++. Walter promised we are 
going to have something like that someday. OpenC++ allows you to write 
classes which extend the compiler, and re-engineer code or introduce new 
syntactic constructs.
well, we do a full D runtime compilation with the dmd compiler in our codebase, this works great, and lets people script stuff, and add to our existing app. mess actually.. and for "compile-time reflection", that should be part of the metaprogramming capabilities of a language, namely for the template-parts.. like typeof(T).children // simple serialisation example.. foreach(type t; typeof(T).children) { file<<t<<" "; } all we need is a nice typeof(...) wich returns an object of type "type".. :D
Nov 25 2003
prev sibling parent "Sean L. Palmer" <palmer.sean verizon.net> writes:
"Ilya Minkov" <minkov cs.tum.edu> wrote in message
news:bptodb$28ni$1 digitaldaemon.com...
 Adam Treat wrote:
 Can D achieve C++ link capability by incorporating a general C++
 introspection library?
Urgh... Have you ever seen a C++ introspection library? E.g. one written in C++? In general, you cannot introspect C++ from itself or by looking at object code... 'Cmm' can do it, but it is an extended C++ compiler which interleaves storage with type information, which is not even complete enough. And if you had unified access to some introspection information, it would still make use pretty masochistic. Unless you like climbing through dozens of closures at each step. So forget it.
It seems to me like a weak design that needs to look at data that it (the program) should already know, such as its own types. I've never needed that, aside from streaming, and that can be solved in numerous ways.
 Perhaps some changes would need to be made to the specs, but IMO C++
 link compatibility would increase the usefullness of D by orders of
 magnitude.  I
Fairly true. I think some (commercal?) compilers will carry link compatibility as a bonus.
Right.
 would love to use D to do KDE/Qt programming without the necessity of
 a C++ -> C -> D binding.
We have a SWIG port now. It generates multiple wrappers which let you use the library naturally, as you do in C++, unlike the introspection method... Maybe we'll have better generator someday. But still, it's the only feasible way.


volatile CV-specifiers in C++? Imagine if you could *define* new ones of those and attach symbolic meaning (like preconditions/postconditions) onto them? Think how easy it would be to instrument a codebase. Apply one to a class and all its members get it by default. Specify your own types of protection like readonly (in fact you could probably do "alias const readonly;") little language, with v2.0 it is actually usable if you don't mind writing some assembly at the bottom end. Well maybe it could be a good scripting language. Sean
Nov 24 2003