Page 1 of 5 123 ... LastLast
Results 1 to 10 of 47

Thread: Merging In The GNU D Language Compiler To GCC

  1. #1
    Join Date
    Jan 2007
    Posts
    15,098

    Default Merging In The GNU D Language Compiler To GCC

    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

  2. #2
    Join Date
    Jul 2011
    Posts
    36

    Thumbs down

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

  3. #3

    Default

    Quote Originally Posted by babali View Post
    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.

  4. #4
    Join Date
    Oct 2009
    Posts
    172

    Default

    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.
    Last edited by kayosiii; 10-05-2011 at 12:36 AM.

  5. #5
    Join Date
    Oct 2009
    Posts
    172

    Default

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

  6. #6
    Join Date
    Sep 2008
    Location
    Vilnius, Lithuania
    Posts
    2,599

    Default

    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.

  7. #7
    Join Date
    Jul 2011
    Posts
    36

    Default

    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.

  8. #8
    Join Date
    Jul 2009
    Posts
    221

    Default

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

    Quote Originally Posted by babali View Post
    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.

  9. #9
    Join Date
    Jul 2011
    Posts
    36

    Default

    Quote Originally Posted by Cyborg16 View Post
    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.

  10. #10
    Join Date
    Sep 2008
    Location
    Vilnius, Lithuania
    Posts
    2,599

    Default

    Quote Originally Posted by babali View Post
    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?

    Quote Originally Posted by Cyborg16 View Post
    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.

Tags for this Thread

Posting Permissions

  • You may not post new threads
  • You may not post replies
  • You may not post attachments
  • You may not edit your posts
  •