Using D as a Better C
June 21, 2017
written by Walter Bright
D as a “Better C” is based on the idea that a project written in C can contain files that are compiled with C or with D. D files can be incrementally and easily added to a C project. Translating existing C files to D can be straightforward.
More specifically, D as Better C (as opposed to being D) means:
- D supports C style programming.
- A D compiled module can be linked in to a C program without the rest of the program needing to adapt to it.
- The D runtime library will not be needed to be linked in.
To make this work, some behaviors of D will need to be adjusted, hence the addition of a `-betterC` compiler switch. Many features of D will not work as Better C, so a subset will be needed.
Effect of -betterC Switch
- `assert()`s, when they fail, will now call the C library assert failure function rather than a function in the D runtime.
- `TypeInfo`’s will not be generated for structs.
- `ModuleInfo` is not generated.
- default library for `WinMain()` and `DllMain()` embedded in object file?
- not linking with phobos runtime library
Not supported D features in Better C
- D classes (C++ classes and COM classes are supported)
- anything that allocates memory using the garbage collector
- static construction/destruction
- unittests
- exceptions
- string switches
- array operations
- synchronized statements
- static closures
- array concatenation and appending
- decoding of unicode strings with for loops
- new expressions
- delete expressions
D features that will work in Better C
- RAII
- templates
- structs
- member functions
- delegates
- nested functions
- dynamic (non-escaping) closures
- `@safe` features
- thread local storage
- CTFE
- template and string mixins
- `ref`, `out`, `lazy` parameters
- `const`, `immutable`, `shared`, `inout` type qualifiers
- array slicing, array parameters
- modules
- C++ interoperability
References
- Better C documentation
- -betterC compiler switch
- Bjarne Stroustrup: "A Better C"