{"id":1044,"date":"2017-08-23T13:01:52","date_gmt":"2017-08-23T13:01:52","guid":{"rendered":"http:\/\/dlang.org\/blog\/?p=1044"},"modified":"2021-10-08T11:08:19","modified_gmt":"2021-10-08T11:08:19","slug":"d-as-a-better-c","status":"publish","type":"post","link":"https:\/\/dlang.org\/blog\/2017\/08\/23\/d-as-a-better-c\/","title":{"rendered":"D as a Better C"},"content":{"rendered":"

Walter Bright<\/a> is the BDFL of the D Programming Language and founder of Digital Mars<\/a>. He has decades of experience implementing compilers and interpreters for multiple languages, including Zortech C++, the first native C++ compiler. He also created Empire, the Wargame of the Century<\/a>. This post is the first in a series<\/a>\u00a0about\u00a0D\u2019s BetterC mode<\/a><\/em><\/p>\n

\n

\"\"D was designed from the ground up to interface directly and easily to C, and to a lesser extent C++. This provides access to endless C libraries, the Standard C runtime library, and of course the operating system APIs, which are usually C APIs.<\/p>\n

But there’s much more to C than that. There are large and immensely useful programs written in C, such as the Linux operating system and a very large chunk of the programs written for it. While D programs can interface with C libraries, the reverse isn’t true. C programs cannot interface with D ones. It’s not possible (at least not without considerable effort) to compile a couple of D files and link them in to a C program. The trouble is that compiled D files refer to things that only exist in the D runtime library, and linking that in (it’s a bit large) tends to be impractical.<\/p>\n

D code also can’t exist in a program unless D controls the main()<\/code> function, which is how the startup code in the D runtime library is managed. Hence D libraries remain inaccessible to C programs, and chimera programs (a mix of C and D) are not practical. One cannot pragmatically “try out” D by add D modules to an existing C program.<\/p>\n

That is, until Better C came along.<\/p>\n

It’s been done before, it’s an old idea. Bjarne Stroustrup wrote a paper in 1988 entitled “A Better C<\/a>“. His early C++ compiler was able to compile C code pretty much unchanged, and then one could start using C++ features here and there as they made sense, all without disturbing the existing investment in C. This was a brilliant strategy, and drove the early success of C++.<\/p>\n

A more modern example is Kotlin, which uses a different method. Kotlin syntax is not compatible with Java, but it is fully interoperable with Java, relies on the existing Java libraries, and allows a gradual migration of Java code to Kotlin<\/a>. Kotlin is indeed a “Better Java”, and this shows in its success.<\/p>\n

D as Better C<\/h3>\n

D takes a radically different approach to making a better C. It is not an extension of C, it is not a superset of C, and does not bring along C’s longstanding issues (such as the preprocessor, array overflows, etc.). D’s solution is to subset the D language, removing or altering features that require the D startup code and runtime library. This is, simply, the charter of the -betterC<\/code> compiler switch.<\/p>\n

Doesn’t removing things from D make it no longer D? That’s a hard question to answer, and it’s really a matter of individual preference. The vast bulk of the core language remains. Certainly the D characteristics that are analogous to C remain. The result is a language somewhere in between C and D, but that is fully upward compatible with D.<\/p>\n

Removed Things<\/h3>\n

Most obviously, the garbage collector is removed, along with the features that depend on the garbage collector. Memory can still be allocated the same way as in C – using malloc()<\/code> or some custom allocator.<\/p>\n

Although C++ classes and COM classes will still work, D polymorphic classes will not, as they rely on the garbage collector.<\/p>\n

Exceptions, typeid, static construction\/destruction, RAII, and unittests are removed. But it is possible we can find ways to add them back in.<\/p>\n

Asserts are altered to call the C runtime library assert fail functions rather than the D runtime library ones.<\/p>\n

(This isn’t a complete list, for that see http:\/\/dlang.org\/dmd-windows.html#switch-betterC<\/a>.)<\/p>\n

Retained Things<\/h3>\n

More importantly, what remains?<\/p>\n

What may be initially most important to C programmers is memory safety in the form of array overflow checking, no more stray pointers into expired stack frames, and guaranteed initialization of locals. This is followed by what is expected in a modern language — modules, function overloading, constructors, member functions, Unicode, nested functions, dynamic closures, Compile Time Function Execution, automated documentation generation, highly advanced metaprogramming, and Design by Introspection.<\/p>\n

Footprint<\/h3>\n

Consider a C program:<\/p>\n

#include <stdio.h>\r\n\r\nint main(int argc, char** argv) {\r\n    printf(\"hello world\\n\");\r\n    return 0;\r\n}\r\n<\/pre>\n
It compiles to:<\/p>\n
_main:\r\npush EAX\r\nmov [ESP],offset FLAT:_DATA\r\ncall near ptr _printf\r\nxor EAX,EAX\r\npop ECX\r\nret\r\n<\/pre>\n
The executable size is 23,068 bytes.<\/p>\n
Translate it to D:<\/p>\n
import core.stdc.stdio;\r\n\r\nextern (C) int main(int argc, char** argv) {\r\n    printf(\"hello world\\n\");\r\n    return 0;\r\n}\r\n<\/pre>\n
The executable size is the same, 23,068 bytes. This is unsurprising because the C compiler and D compiler generate the same code, as they share the same code generator. (The equivalent full D program would clock in at 194Kb.) In other words, nothing extra is paid for using D rather than C for the same code.<\/p>\n
The Hello World<\/code> program is a little too trivial. Let’s step up in complexity to the infamous sieve benchmark program:<\/p>\n
#include <stdio.h>\r\n\r\n\/* Eratosthenes Sieve prime number calculation. *\/\r\n\r\n#define true    1\r\n#define false   0\r\n#define size    8190\r\n#define sizepl  8191\r\n\r\nchar flags[sizepl];\r\n\r\nint main() {\r\n    int i, prime, k, count, iter;\r\n\r\n    printf (\"10 iterations\\n\");\r\n    for (iter = 1; iter <= 10; iter++) {\r\n        count = 0;\r\n        for (i = 0; i <= size; i++)\r\n            flags[i] = true;\r\n        for (i = 0; i <= size; i++) {\r\n            if (flags[i]) {\r\n                prime = i + i + 3;\r\n                k = i + prime;\r\n                while (k <= size) {\r\n                    flags[k] = false;\r\n                    k += prime;\r\n                }\r\n                count += 1;\r\n            }\r\n        }\r\n    }\r\n    printf (\"\\n%d primes\", count);\r\n    return 0;\r\n}\r\n<\/pre>\n
Rewriting it in Better C:<\/p>\n
import core.stdc.stdio;\r\n\r\nextern (C):\r\n\r\n__gshared bool[8191] flags;\r\n\r\nint main() {\r\n    int count;\r\n\r\n    printf(\"10 iterations\\n\");\r\n    foreach (iter; 1 .. 11) {\r\n        count = 0;\r\n        flags[] = true;\r\n        foreach (i; 0 .. flags.length) {\r\n            if (flags[i]) {\r\n                const prime = i + i + 3;\r\n                auto k = i + prime;\r\n                while (k < flags.length) {\r\n                    flags[k] = false;\r\n                    k += prime;\r\n                }\r\n                count += 1;\r\n            }\r\n        }\r\n    }\r\n    printf(\"%d primes\\n\", count);\r\n    return 0;\r\n}<\/pre>\n
It looks much the same, but some things are worthy of note:<\/p>\n