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