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?

Also, what about C#
style attributes?  I think this was one of the best
features of C#.

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.

> Also, what about C#
> style attributes?  I think this was one of the best features of C#. 

What would they be useful for?

 -- andy

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.

> Also, what about C# style attributes?  I think this was one of the
> best features of C#.

What is that? I'm not closely familiar with C#.

-eye

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.

>> Also, what about C# style attributes?  I think this was one of the best features of C#.
> 
>What is that? I'm not closely familiar with C#.

C# attributes are basically a way to encode meta-information about a function
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/vclrfIntroductionToAttributes.asp">two</a>.

"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.
>
> > Also, what about C# style attributes?  I think this was one of the best features of C#.
>
> What is that? I'm not closely familiar with C#.

This is the coolest feature of C# 1.0, I think... you know const and 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;")

It's too bad my industry can't use a tool like C#, as I think it's a neat 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

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.

> C# attributes are basically a way to encode meta-information about a function 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/vclrfIntroductionToAttributes.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

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. much bether than the way those c# reflection examples show up, they are a big 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