[Home]
[Search]
[D]
Last modified Oct 24, 2002.
FAQ
The same questions keep cropping up, so the obvious thing to do is
prepare a FAQ.
Why the name D?
The original name was the Mars Programming Language. But my friends kept
calling it D, and I found myself starting to call it D.
The idea of D being a successor to C goes back at least as far as 1988,
as in this thread.
Where can I get a D compiler?
Right here.
Is there a linux port of D?
Burton Radons has prepared a
linux port.
What about templates?
D now has a template proposal.
Why emphasize implementation ease?
Isn't ease of use for the user of the language more important? Yes, it is.
But a vaporware language is useless to everyone. The easier a language
is to implement, the more robust implementations there will be. In C's
heyday, there were 30 different commericial C compilers for the IBM PC.
Not many made the transition to C++. In looking at
the C++ compilers on the market today, how many years of development went
into each? At least 10 years? Programmers waited years
for the various pieces of C++ to get implemented after they were specified.
If C++ was not so enormously popular, it's doubtful that very complex features
like multiple inheritance, templates, etc., would ever have been implemented.
I suggest that if a language is easier to implement, then it is likely also
easier to understand. Isn't it better to spend time learning to write better
programs than language arcana? If a language can capture 90% of the power of
C++ with 10% of its complexity, I argue that is a worthwhile tradeoff.
Why is [expletive deleted] printf in D?
printf is not typesafe. It's old fashioned. It's not object-oriented.
It's not usable with user-defined types. printf is guilty as
charged. But it's just so darned useful. Nothing beats it for banging out
a quick dump of a value when debugging.
Note: printf is actually not really
part of D anyway, but since D provides easy access to C's runtime library,
D gets it when needed.
Will D be open source?
The front end for D is open source, and the source comes with the
compiler.
There is a SourceForge
project underway to create a Gnu implementation of
D from this.
Why fall through on switch statements?
Many people have asked for a requirement that there be a break between
cases in a switch statement, that C's behavior of silently falling through
is the cause of many bugs.
The reason D doesn't change this is for the same reason that integral
promotion rules and operator precedence rules were kept the same - to
make code that looks the same as in C operate the same. If it had subtly
different semantics, it will cause frustratingly subtle bugs.
Why should I use D instead of Java?
D is distinct from Java in purpose, philosophy and reality.
Here are some of the ways,
in no particular order:
- D has Design by Contract.
- D has unit testing.
- D has lightweight arrays.
- D has lightweight objects.
- D has enumerated types.
- D has typedefs.
- D has function delegates.
- D has inline assembler.
- D has direct access to hardware I/O ports.
- D has a considerably smaller executable size (no VM needed).
- D has out and inout function parameters, i.e. functions can return
multiple values.
- D has code execution speed that is as fast or faster than C.
- D has direct support of all C types.
- D has support for complex and imaginary floating point types,
ASCII, unsigned types, etc.
- D has arrays of bits.
- D has associative arrays.
- D supports direct interfacing to C and operating system APIs.
- D has version control as part of the language.
- Debug D programs with common, existing C debuggers.
- D has a minimal learning curve for C programmers.
- D has turn-offable array bounds checking.
- D has support for assert()s and debug statements, and other
tunable runtime error checking.
- D has no need for external C functions.
- D's full library source means complete control over generated app.
- D's floating point is the best available on the target machine.
- D has strings implemented as arrays, not objects.
- D does not do dynamic class loading.
- D works with your other existing dev tools (make, linkers, debuggers,
etc.)
Java is designed to be write once, run everywhere. D is designed for writing
efficient native system apps. Although D and Java share the notion that
garbage collection is good and multiple inheritance is bad <g>, their
different design goals mean the languages have very different feels.
What does D have that C++ doesn't?
D has many thing that C++ doesn't have:
- design by contract
- unit tests
- versioning
- dynamic arrays
- associative arrays
- garbage collection
- out parameters
- finally blocks
- synchronized functions
- modules
- defined order for static constructors
- guaranteed initialization
- array bounds checking
- no array aliasing problem
- defined way to do inline assembler
- builtin support for strings
- imaginary numbers
- complex numbers
- struct member alignment
- real typedefs
- bit arrays
Doesn't C++ support strings, bit arrays, etc. with STL?
In the C++ standard library are mechanisms for doing strings,
bit arrays, dynamic arrays, associative arrays, bounds checked
arrays, and complex numbers.
Sure, all this stuff can be done with libraries,
following certain coding disciplines, etc. But you can also do
object oriented programming in C (I've seen it done).
Isn't it incongruous that something like strings,
supported by the simplest BASIC interpreter, requires a very
large and complicated infrastructure to support?
Just the implementation of a string type in STL is over two
thousand lines of code, using every advanced feature of templates.
How much confidence can you have that this is all working
correctly, how do you fix it if it is not, what do you do with the
notoriously inscrutable error messages when there's an error
using it, how can you be sure you are using it correctly
(so there are no memory leaks, etc.)?
D's implementation of strings is simple and straightforward.
There's little doubt how to use it, no worries about memory leaks,
error messages are to the point, and it isn't hard to see if it
is working as expected or not.
Can't garbage collection be done in C++ with an add-on library?
Yes, I use one myself. It isn't part of the language, though, and
requires some subverting of the language to make it work.
Using gc with C++ isn't for the standard or casual C++ programmer.
Building it into the
language, like in D, makes it practical for everyday programming chores.
GC isn't that hard to implement, either, unless you're building one
of the more advanced ones. But a more advanced one is like building
a better optimizer - the language still works 100% correctly even
with a simple, basic one. The programming community is better served
by multiple implementations competing on quality of code generated
rather than by which corners of the spec are implemented at all.
Can't unit testing be done in C++ with an add-on library?
Sure. Try one out and then compare it with how D does it.
It'll be quickly obvious what an improvement building it into
the language is.
Why have an asm statement in a portable language?
An asm statement allows assembly code to be inserted directly into a D
function. Assembler code will obviously be inherently non-portable. D is
intended, however, to be a useful language for developing systems apps.
Systems apps almost invariably wind up with system dependent code in them
anyway, inline asm isn't much different. Inline asm will be useful for
things like accessing special CPU instructions, accessing flag bits, special
computational situations, and super optimizing a piece of code.
Before the C compiler had an inline assembler, I used external assemblers.
There was constant grief because many, many different versions of the
assembler were out there, the vendors kept changing the syntax of the
assemblers, there were many different bugs in different versions, and even
the command line syntax kept changing. What it all meant was that users
could not reliably rebuild any code that needed assembler. An inline
assembler provided reliability and consistency.
Is there a GUI library for D?
Since D can call C functions, any GUI library with a C interface
is accessible from D. Burton Radons has also done a
D GUI.
Copyright (c) 1999-2002 by Digital Mars, All Rights Reserved