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 multiparadigm: supporting imperative, object oriented, and template metaprogramming 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.
6. 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.
7. 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.
8. 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.
9. Unit testing – makes it simple to include unit tests directly within each class to validate it.
10. 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.
11. 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.
12. No Macro text preprocessor – the source of so much potential ugliness – gone!
13. Built-in strings – sure the STL has them but being built in to the language certainly seems like a reasonable way to go.
14. 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.
2. Resizable arrays – being built in to the language is the way to go for such a basic operation.
3. Array slicing – another minor convenience.
4. Associative arrays – an STL plus that is built in to the language.
5. String switches – its definitely convenient at times.
6. Thread synchronization primitives – with the prevalence of threads having basic sync support in the language is a timesaver.
7. Typesafe variadic arguments – gets around C++ clunky access to an unknown number of arguments.
8. Documentation comments – a consistent way of documenting code.
9. 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 dealbreaker that would make me prefer Managed C++ from Microsoft over D is the lack of interop with C++. D is very proud of it’s 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 commitee 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 performace based coding across multiple platforms. It certainly might be possible to use an auto-wrapper generater 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 seemless interfacing is feasible.
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).