Merging In The GNU D Language Compiler To GCC

[phoronix]

Phoronix: Merging In The GNU D Language Compiler To GCC

Nearly one year ago I wrote about Digital Mars wanting to merge the GNU D Compiler into GCC. Finally it looks like merging the compiler for the D programming language is nearing a point of reality...

http://www.phoronix.com/vr.php?view=OTk2NA

[babali]

Anyway the D constness is kind of broken, and it's a garbage collected language...

[AnonymousCoward]

Anyway the D constness is kind of broken, and it's a garbage collected language...

The garbage collector is optional in D. Also, asserting that D's constness were broken seems to require a justification.

[kayosiii]

This is probably a good starting point to understanding the const problem.
http://stackoverflow.com/questions/4...cal-const-in-d.

GC in D is optional but some language features and parts of the standard library do rely on GC being available. The former are features not available in C/C++ so I don't see that as a huge issue. The library could be a problem though (I expect long term that a non GC library will appear if it turns out that a lot of people want to use D without garbage collection). From what I have been able to glean GC code should run slightly faster than non GC code (less system memory calls) but use 2-5 times as much memory. It's a *lot* harder to get a memory leak when using a GC so in a real world app that runs a long time you may end up being ahead on memory usage too. The other issue with gc is that the actual gc call can make your application unresponsive for a small amount of time; If your application had to meet a hard deadline (realtime app) this potentually would be a problem. In D you can have GC and non GC code in the same app and you have a degree of control over when the gc actually runs.

On the whole I like where D is going. It tries to make the easiest way of doing things the most reliable and avoid you making stupid mistakes by design. It also allows you to optimise all the way down to assembly language in the parts of the code where you need performance. I can't think of another language that does both of these things.

[kayosiii]

It would also be nice to have gdc merged into gcc proper... It will make it just that much easier to distribute a d based program through launchpad (ppa).

[GreatEmerald]

I use D as my primary language for development, and while the language itself is everything I could ever hope for, the compilers themselves still need a lot of work. GDC, last I heard, was behind DMD by quite a bit, so it is useful mostly if you program in D1, but not D2. For the latter, you want to get DMD. And DMD itself still has issues, like no support for a -fPIC argument. And RDMD, the dependency solver that comes with DMD, is a very awesome concept, but doesn't quite work with libraries of any kind right now, only with executables.

But once again, I haven't followed the development of GDC as closely, so maybe they have decent D2 support now, but it definitely won't ever match DMD, unless Digital Mars goes out of business.

As for D itself having garbage collection - that's the whole point of the language. It might be slower that way, but it saves developers a lot of trouble, since you no longer have to care about obscure things like memory management and can do more work on the conceptual level. It's also easy to learn and more practical that way, while still leaving developers plenty of choices.

[babali]

The proplem with garbage collection is that to understand how your program work, you have to understand how the garbage collection work.
And you have to write you program depending on how your garbage collector work (i know it possible to change the gc implementation which makes this task harder).
In C++ you can manage your memory with RAII+refcounting so easily that I see no good reason to have a gc.

[Cyborg16]

What about LDC? I've been out of the D scene for a couple of years, but that did look promising.

In C++ you can manage your memory with RAII+refcounting so easily that I see no good reason to have a gc.

One reason: copy-on-write arrays (in particular, strings). I guess you could do this with ref-counting, but I don't know if it's worth the overhead. But I partially agree with babali since memory management in C++ is usually not hard, and D's on-the-stack structs vs. on-the-heap classes are a bit wierd.

[babali]

One reason: copy-on-write arrays (in particular, strings). I guess you could do this with ref-counting, but I don't know if it's worth the overhead.

It depends on the implementation, but in the gnu stdc++, std::string are COW.

[GreatEmerald]

The proplem with garbage collection is that to understand how your program work, you have to understand how the garbage collection work.

Again, that's the whole idea. You don't need to care about how your program works, as long as it works. That's the idea behind D - make it simple to understand and use while abstracting things like memory management. For all I care, there could be no memory to begin with. The boost in performance is not worth learning the whole mechanics of RAM. Pointers themselves are obscure enough, and you could very well live without them. So if you are fine with a low-level language, then why comment about D in the first place?

What about LDC? I've been out of the D scene for a couple of years, but that did look promising.

That's still under development. It can't compile much yet, but it still looks promising.