Coming From

From D Wiki
Jump to: navigation, search

When coming from another language it is good to find out where D stands in relation to it. There is the feature list which states if a feature exists or not and possibly an explanation. For a side-by-side comparison of many languages: Languages vs D or you can look at code snippets of from Rosetta Code.

A very superficial way to find out the popularity of D in relation to other languages can is at the Tiobe Index website.

For information about syntactical differences or gotchas when coming from another language choose your language below.

General Comparison

Specific Language


If you are interested in converting your code to D start by looking at the Porting Overview.

Walter Bright has observed that when you first start writing D you tend to write it like the existing languages you are familiar with. In time you may choose to make use of the higher-level features of D that make writing D code a pleasure rather than a chore. But programming is about using a tool to solve a problem, and there is no dogma in D that there is only one way to do it. Very often you don't need to make use of advanced D features like metaprogramming, templates, and compile time function execution to achieve a useful result quickly.

Converting C code with explicit memory allocation and resource management? Make use of the scope(exit) feature to automatically free pointers and close files when your function or code block finishes (whether successfully or on error).

From Adam Ruppe "D this Week"

Don't be afraid to do things the C way.

I've observed a lot of D programmers worrying about doing things the "D way", including asking how to convert working C standard library code to D or lamenting the lack of a D library to replace some C code.

There's value in this: D can do a lot of things C can't. The "D way" can often be safer, less bug-prone, more beautiful, or more efficient than C code and libraries.

However, D is also a language for practical programmers and sometimes code that works today is more important than ideal code that might be written at some point later. This is why D gives full access to C facilities, so you can use them!

If you know how to do something with scanf, you can still use it in D, even while mixing with std.stdio's functions. Simply import core.stdc.stdio; and you can use all your familiar C functions.

Want to do memory management the C way? Simply import core.stdc.stdlib; and use malloc and free. Combined with D features like scope(exit) to help with freeing and struct semantics to manage ownership you can rest assured that using D will offer advantages over C where needed, without tying your hands when you want to do things the old, familiar way.

If you have a third-party C API, you don't have to reimplement that functionality in D to take advantage of it (though, there are times you do want to, to leverage D's unique offers). You can simple write an extern(C) function declaration and call the function directly from D, or you can also use dynamic library loading in D, the same way as in C, e.g. with dlopen or LoadLibrary.

If you know how to solve a problem with pointers, structs, loops, and procedures as in C, you can use them in D too. Yes, the standard library offers a number of excellent range-based algorithms and help for coding in a functional programming style, and learning these is worth the investment. But, if you already know how to do it in C and need it done now, don't let Phobos' allure be an enemy to your productivity. You can still do your work with familiar language features.

Moving to D opens up a whole new world of superior programming. But it doesn't shut you out of the old world. D aims to be a practical language for working programmers - remember that as you work with it. The new features will still be there to try tomorrow.