The D Programming Language

The D Programming Language – a Pleasant Surprise

From the D website,

“D is a systems programming language. Its focus is on combining the power and high performance of C and C++ with the programmer productivity of modern languages like Ruby and Python. Special attention is given to the needs of quality assurance, documentation, management, portability and reliability.

D is statically typed, and compiles direct to native code. It’s multi-paradigm: supporting imperative, object-oriented, and template meta-programming styles. It’s a member of the C syntax family, and its look and feel is very close to C++’s.”

This language first piqued my interest about 2 years ago. At the time I saw it as a great idea but wanted to wait to see if it would catch on at all. Since then I have been hearing about it from time to time and finally decided it was time to take a close look. And I’m really glad I did.

This article mainly compares C++ to D from the perspective of what C++ is missing that D has. If you haven’t read my last article about what I love about C++, you’ll probably want to do that first.

Favorite additions C++ is missing:

  1. Garbage Collection – this is almost always faster and more efficient use of runtime cycles and the developer’s development cycles; a total no-brainer in most cases. You can do manual memory allocation when you think you know better.
  2. Nested functions – The nested function has full access to the local variables of the function it is nested in. Being able to break up large functions in the scope of the calling function makes things sensible and clean.
  3. Inner (adaptor) classes – Nested classes support access to the variable scope of the calling class. Use a static nested class to prohibit access.
  4. Properties – Being able to use the syntactic sugar of values with underlying functions makes good sense. Why shouldn’t value be able to be abstracted out and have underlying functions?

5. foreach – cycle through all the elements and let the compiler decide the most efficient way.

  1. Implicit Type Inference – this is coming to C# soon as well. It’s nice not to have to specify the type when it is already specified by what it it’s being set equal to.
  • Strong typedefs – This one is especially nice. You want to create a typedef that isn’t considered the same as the original as function signatures are concerned. C++ forces you to create a class to do this thing that should be simple.
  • Contract Programming – puts your in and out contract constraints into the code in a clean, consistent way. The compiler can now better optimize and inherit contract constraints.

  • Unit testing – makes it simple to include unit tests directly within each class to validate it.

  • Static construction order – Being able to explicitly define in what order static objects are created in shouldn’t be too much to ask. I’ve seen more than a few projects bit by this in C++. In C++ you have no guarantee when statics will be initialized. Interdependencies in C++ can leave you shaking your head as you unravel the evil.

  • Guaranteed initialization – you have to explicitly say that you want no initialization for performance reasons. 95% of the time not initializing is a mistake – let the compiler do it for you.

  • No Macro text preprocessor – the source of so much potential ugliness – gone!

  • Built-in strings – sure the STL has them but being built-in to the language certainly seems like a reasonable way to go.

  • Array bounds checking – built-in support for checking bounds on all arrays. Turn it on or off – very nice. How many times in C++ have you wished you could flip a switch and make sure nothing was going out of range at runtime. Maybe you should use the STL all the time, but I don’t know anyone who doesn’t use built-in arrays at least some of the time.

  • Nice to haves C++ is missing:

    1. Function delegates – a convenient way to point at member functions.
  • Resizable arrays – being built-in to the language is the way to go for such a basic operation.
  • Array slicing – another minor convenience.

  • Associative arrays – an STL plus that is built-in to the language.

  • String switches – its definitely convenient at times.

  • Thread synchronization primitives – with the prevalence of threads having basic sync support in the language is a timesaver.

  • Type-safe variadic arguments – gets around C++ clunky access to an unknown number of arguments.

  • Documentation comments – a consistent way of documenting code.

  • Try-catch-finally blocks – I’m still not a big fan of exceptions. I blame it on my background in-game programming.

  • There are more advantages over C++, but I just wanted to mention a few of the highlights.
    For a complete comparison of D vs. C, C++, C# and Java go to the D website’s comparison

    Doing a little deeper digging under the covers I found a few things I didn’t like – and one was a deal-breaker.

    First of all – all classes in each module have access to each others private data. There is no way to turn this off. This forces a loss of encapsulation – a concept i don’t agree with.

    Unfortunately the deal breaker that would make me prefer Managed C++ from Microsoft over D is the lack of interop with C++. D is very proud of its simple interop with C. But unlike Microsoft’s Managed C++, D requires cumbersome mechanisms to interop with C++. This is extremely unfortunate and leaves me wishing the C++ standards committee would make C++ over time more like D.

    All in all, D appears to be a very promising language with much to offer. With more straightforward support for coexisting with C++, I would think it would be a shoe-in to eventually gain mainstream popularity. It seems very suitable for performance based coding across multiple platforms. It certainly might be possible to use an auto-wrapper generator like SWIG to bridge C++ libraries to D.

    I will admit that I have only given D a laymen’s overview. I haven’t coded at length in it yet. However I think I’ll end up coding lower level constructs in C++ and using C# for higher level garbage collected code.

    In my mind D is a pleasant surprise but doesn’t quite fit the bill. I would love to see more convenient interfacing with C++ to the extent that such seamless interfacing is feasible.

    11 thoughts on “The D Programming Language – a Pleasant Surprise

    1. larsivi

      I’ve been a D user for a long time now, and have serious problems looking at C++ code again ;) Anyway, nice writeup. I would have put array slicing and delegates up in the big features section though. Array slicing is particularly useful when dealing with text, as all slices of a string are only references, and thus very cheap to handle (given that you don’t need to edit any of them).

      As for delegates, not only are they useful (they’re function pointers for an OO language, after all), but in D you can create them anonymously. A function

      void registerDelegate(void delegate(bool) dg) { … }

      can be called like this

      registerDelegate((bool b){ some code using b here; });

    2. Duck Destructor

      You would have loved Borland’s Object Pascal. It had many of the significant things you mention. I used to program in C++ but switched completely to OP eventually. C++ wasted so much of my life, although I did enjoy it I have to say.

      Anyway, its really the fault of ducks. Did you know that? If you come across a duck then the best thing to do is kill it. Kill that duck!!!

    3. Steve Riley Post author


      It’s great you’ve been using D so much – I’d love to know the types of environments and the things you are doing with it. I really want to get some time and try my hand at it as well – it definitely seems to handle C++’s issues well.

      Also, good points about delegates and slicing – I’m not sure how I overlooked them:)

    4. Steve Riley Post author

      Duck Destructor,

      I programmed quite a bit in Turbo Pascal in the early 90’s. It was truly amazing with lightning fast compile times.

      I never worked with Object Pascal but I hear quite a few of the concepts made it into C# (because of the Anders Hejlsberg connection).

    5. Duck Destructor


      OP/Delphi was as fast compiling as Turbo Pascal. I remember a reviewer (in the early days) telling how he waited several minutes not realising that the compile had finished within 2 seconds! And that was in 1994.

      Of course with a 1 pass compiler there’s a bunch of stuff you can’t do, and I remember thinking a nice little pre-processor might be nice. But delphi didn’t have the hooks for it, and it never happened.

      Don’t forget to run over a duck today, and maybe one tomorrow, too.

    6. Eli Gottlieb

      Just piping in on behalf of Object Pascal. It’s a good language, and I still use it to code my hobby operating system.

      Actually, there are a few features from D like garbage collection, foreach, contracts and anonymous functions I’d like to see in Object Pascal.

      Still, my only real complaint with the OP language is that getting it to run on bare metal (under either the GNU Pascal Compiler or the Free Pascal Compiler) requires writing a small runtime library with file-handling functions that no bare-metal code will ever need. I think any language hoping to call itself a systems programming language (listen up D!) should absolutely minimize the size of its run-time library. MINIMIZE!

    7. larsivi

      I wonder why this showed up on DZone again ;) I can’t remember the deal breaker stuff from last, so I suppose that was added.

      As for your question on what I’ve done with D, I’ve been mostly a dabbler, but I have had a 3 month spell as a consultant on a commercial application written in D, and over the last 8 months I’ve been involved in the development of improved base libraries, due for release soonish. My blog linked above is mainly about D, too.

      I personally couldn’t care less about C++ interoperability (in fact I have argued against it within the community, mostly because there are so many other more important things to do for a community that still is mostly non-profit), and even less MS C++. C++ is historically riddled with compatibility problems between different compiler vendors, and especially so on Windows. I guess MS now is almost the only one still in real action, except for those using gcc under cygwin or mingw.

      Implementing interop with C++ requires 1) enormous amounts of man hours, C++ is a ridiculously hard language to support, and so only large corps like MS are likely to afford it 2) C++ is so different from most other languages, so to support it fully you need to cripple it like in Managed C++, or wrap it with C, and then D, like the tool bcd.gen (use GCC) 3) possibly drop Windows, as C++ ABI is actually fairly stable and standardized on unix platforms.

      Now, whether one needs C++ interop is an opinion you’re entitled to have, not all in the community agree with me. As it is though, I don’t consider the lack of this a shortcoming in the language, but rather an option for the future, D should for instance be eminently viable for implementation on top of the .Net framework for anyone willing to do so (someone started and came quite far, but the hd crashed …)

      And a comment to Eli Gottlieb. It might not be clear from the DigitalMars documentation, but what is called the standard library, consists of two parts, the language runtime, and the rest. This rest can be thought of as your typical standard C library. The runtime part includes the GC (memory allocation and such) and implementation of some of the parts of the language, Object, TypeInfo and associative arrays. There is no file-handling in this runtime part, and as long as you don’t use any functionality from the other part, this runtime part is what will be linked in. Since a couple of minimal kernels has been shown to work using D (functionality needing the GC, like dynamic arrays, cannot be used unless there is a GC implementation there, of course), I don’t think anyone can claim that D cannot be used on the bare metal.

    8. redsolo

      Hmmm, I don’t like adding unit test code into the class file itself. For me unit test code is most of the time not very pretty, a class can have up to 10-20 tests for different scenarios; and adding that surplus of methods into a class does not make it easier to read and understand. Sure the example looks nice, but we are not talking real classes there.

      Yes, there is a problem when the test code is not updated correctly. But that is a more sign that you are creating software under a high pressure, and the question is that perhaps instead of updating the test code it may be deleted in order to get everything to compile and out the door.

      Contract programming would be nice to have, but the solution offered by D was not very good (at least in the example). The code to check the in parameter is larger than a simple “if(x

    9. Steve Riley Post author


      It’s funny – I changed the permalinks on my articles so that the URL now uses the article title instead of numbers (http://xxxx/this-is-your-article-title/ vs http://xxxxxx/p?22) and didn’t think about my articles possibly being resubmitted. In the last few days I’m seeing them resurface in places like reddit and dzone. They need to work a bit more like dig and tell you about similar articles (which in this case would have flag the same articles:)).

      I agree about C++ – I’d prefer not to have to interop with it and use something like D across the board. I always end up using a few opensource libraries that are dealbreakers. One in particular I use a lot is OpenSceneGraph for 3D work. It sits on top of OpenGL but adds an SGI Performer type library.

      I’ll definitely read your blog – I’m really interested to hear all your thoughts about D.

    10. Will

      Another advantage of D over C++: Gone is the ‘include’ model and parsing is much simplified, so for large projects, compile times scale much better. Combined with the lack of a text based macro system, we may actually see rich refactoring support for D.

    11. Steve Riley Post author


      I agree completely about the include model and macros. These are two of the stickiest legacy elements of c++ that must make refactoring tools a nightmare to write.


    Leave a Reply