+
+
+
+D vs C/C++/C#/Java
+Rationale for Builtins
+Converting C to D
+Converting C++ to D
+The C Preprocessor vs D
+D strings vs C++ std::string
+D complex vs C++ std::complex
+D Contract Programming vs C++
+
+ |
+
+
Programming in D for C Programmers
@@ -109,23 +147,19 @@
The C Way
-
-
- sizeof(int)
+ sizeof(int)
sizeof(char *)
sizeof(double)
- sizeof(struct Foo) |
+ sizeof(struct Foo)
The D Way
Use the size property:
-
-
- int.size
+ int.size
(char *).size
double.size
- Foo.size |
+ Foo.size
@@ -133,26 +167,22 @@
The C Way
-
-
- #include <limits.h>
+ #include <limits.h>
#include <math.h>
CHAR_MAX
CHAR_MIN
ULONG_MAX
DBL_MIN
- |
+
The D Way
-
-
- char.max
+ char.max
char.min
ulong.max
double.min
- |
+
@@ -160,9 +190,7 @@
C to D types
-
-
- bool => bit
+ bool => bit
char => char
signed char => byte
unsigned char => ubyte
@@ -181,7 +209,7 @@
_Imaginary long double => imaginary
_Complex long double => complex
- |
+
Although char is an unsigned 8 bit type, and
wchar is an unsigned 16 bit type, they have their own separate types
@@ -195,9 +223,7 @@
The C Way
-
-
- #include <fp.h>
+ #include <fp.h>
NAN
INFINITY
@@ -211,13 +237,11 @@
DBL_MAX_EXP
DBL_MIN_10_EXP
DBL_MIN_EXP
- |
+
The D Way
-
-
- double.nan
+ double.nan
double.infinity
double.dig
double.epsilon
@@ -226,34 +250,30 @@
double.max_exp
double.min_10_exp
double.min_exp
- |
+
The C Way
-
-
-
+
#include <math.h>
float f = fmodf(x,y);
double d = fmod(x,y);
long double e = fmodl(x,y);
- |
+
The D Way
D supports the remainder ('%') operator on floating point operands:
-
-
-
+
float f = x % y;
double d = x % y;
extended e = x % y;
- |
+
@@ -265,26 +285,22 @@
is NAN, and few C compilers check for it (the Digital Mars
C compiler is an exception, DM's compilers do check for NAN operands).
-
-
-
+
#include <math.h>
if (isnan(x) || isnan(y))
result = FALSE;
else
result = (x < y);
- |
+
The D Way
D offers a full complement of comparisons and operators
that work with NAN arguments.
-
-
- result = (x < y); // false if x or y is nan
- |
+ result = (x < y); // false if x or y is nan
+
@@ -296,23 +312,19 @@
and __LINE__ from which an assert macro can be built. In fact,
there appears to be practically no other use for __FILE__ and __LINE__.
-
-
-
+
#include <assert.h>
assert(e == 0);
- |
+
The D Way
D simply builds assert into the language:
-
+
[NOTE: trace functions?]
@@ -322,23 +334,19 @@
The C Way
-
-
-
+
#define ARRAY_LENGTH 17
int array[ARRAY_LENGTH];
for (i = 0; i < ARRAY_LENGTH; i++)
array[i] = value;
- |
+
The D Way
-
-
-
+
int array[17];
array[] = value;
- |
+
@@ -349,46 +357,38 @@
The array length is defined separately, or a clumsy
sizeof() expression is used to get the length.
-
-
-
+
#define ARRAY_LENGTH 17
int array[ARRAY_LENGTH];
for (i = 0; i < ARRAY_LENGTH; i++)
func(array[i]);
- |
+
or:
-
-
-
+
int array[17];
for (i = 0; i < sizeof(array) / sizeof(array[0]); i++)
func(array[i]);
- |
+
The D Way
The length of an array is accessible the property "length".
-
-
-
+
int array[17];
for (i = 0; i < array.length; i++)
func(array[i]);
- |
+
or even better:
-
-
-
+
int array[17];
foreach (int value; array)
func(value);
- |
+
@@ -401,9 +401,7 @@
variable for the length, and then explicitly manage the size of
the array:
-
-
-
+
#include <stdlib.h>
int array_length;
@@ -416,21 +414,19 @@
error("out of memory");
array = newarray;
array[array_length++] = x;
- |
+
The D Way
D supports dynamic arrays, which can be easily resized. D supports
all the requisite memory management.
-
-
-
+
int[] array;
array.length = array.length + 1;
array[array.length - 1] = x;
- |
+
@@ -442,9 +438,7 @@
when can storage be free'd, dealing with null pointers,
finding the length of the strings, and memory allocation:
-
-
-
+
#include <string.h>
char *s1;
@@ -474,23 +468,21 @@
error("out of memory");
s = news;
memcpy(s + lens, hello, sizeof(hello));
- |
+
The D Way
D overloads the operators ~ and ~= for char and wchar arrays to mean
concatenate and append, respectively:
-
-
-
+
char[] s1;
char[] s2;
char[] s;
s = s1 ~ s2;
s ~= "hello";
- |
+
@@ -500,25 +492,21 @@
printf() is the general purpose formatted print routine:
-
-
-
+
#include <stdio.h>
printf("Calling all cars %d times!\n", ntimes);
- |
+
The D Way
What can we say? printf() rules:
-
-
-
+
import stdio;
printf("Calling all cars %d times!\n", ntimes);
- |
+
@@ -530,9 +518,7 @@
not yet encountered in the source file, it is necessary to insert
a function declaration lexically preceding the call.
-
-
-
+
void forwardfunc();
void myfunc()
@@ -544,7 +530,7 @@
{
...
}
- |
+
The D Way
@@ -554,9 +540,7 @@
referenced function declarations twice.
Functions can be defined in any order.
-
-
-
+
void myfunc()
{
forwardfunc();
@@ -566,7 +550,7 @@
{
...
}
- |
+
@@ -574,11 +558,9 @@
The C Way
-
-
-
+
void function(void);
- |
+
The D Way
@@ -586,14 +568,12 @@
say a function takes no arguments, just don't declare it has having
arguments.
-
-
-
+
void function()
{
...
}
- |
+
@@ -604,9 +584,7 @@
Break's and continue's only apply to the innermost nested loop or
switch, so a multilevel break must use a goto:
-
-
-
+
for (i = 0; i < 10; i++)
{
for (j = 0; j < 10; j++)
@@ -621,7 +599,7 @@
}
Louter:
;
- |
+
The D Way
@@ -629,9 +607,7 @@
is the label for an enclosing loop or switch, and the break applies
to that loop.
-
-
-
+
Louter:
for (i = 0; i < 10; i++)
{
@@ -644,7 +620,7 @@
}
}
// break Louter goes here
- |
+
@@ -670,22 +646,18 @@
It's annoying to have to put the struct keyword every time a type is specified,
so a common idiom is to use:
-
-
-
+
typedef struct ABC { ... } ABC;
- |
+
The D Way
Struct tag names are not in a separate name space, they are in the same name
space as ordinary names. Hence:
-
-
-
+
struct ABC { ... };
- |
+
@@ -697,9 +669,7 @@
values and take action based on which one it is. A typical use
for this might be command line argument processing.
-
-
-
+
#include <string.h>
void dostring(char *s)
{
@@ -720,7 +690,7 @@
default: ...
}
}
- |
+
The problem with this is trying to maintain 3 parallel data
structures, the enum, the table, and the switch cases. If there
@@ -740,9 +710,7 @@
strings as well as numbers. Then, the way to code the string
lookup becomes straightforward:
-
-
-
+
void dostring(char[] s)
{
switch (s)
@@ -753,7 +721,7 @@
default: ...
}
}
- |
+
Adding new cases becomes easy. The compiler can be relied on
to generate a fast lookup scheme for it, eliminating the bugs
@@ -769,16 +737,14 @@
program, and woe results if any modules or libraries didn't get
recompiled. To address this, #pragma's are used:
-
-
-
+
#pragma pack(1)
struct ABC
{
...
};
#pragma pack()
- |
+
But #pragmas are nonportable both in theory and in practice from
compiler to compiler.
@@ -788,9 +754,7 @@
Clearly, since much of the point to setting alignment is for
portability of data, a portable means of expressing it is necessary.
-
-
-
+
struct ABC
{
int z; // z is aligned to the default
@@ -804,7 +768,7 @@
int y; // y is word aligned
}
- |
+
@@ -817,9 +781,7 @@
C doesn't allow anonymous structs or unions, which means that dummy tag names
and dummy members are necessary:
-
-
-
+
struct Foo
{ int i;
union Bar
@@ -839,7 +801,7 @@
f.x;
f.y;
f.p;
- |
+
Not only is it clumsy, but using macros means a symbolic debugger won't understand
what is being done, and the macros have global scope instead of struct scope.
@@ -849,9 +811,7 @@
Anonymous structs and unions are used to control the layout in a
more natural manner:
-
-
-
+
struct Foo
{ int i;
union
@@ -867,7 +827,7 @@
f.x;
f.y;
f.p;
- |
+
@@ -877,31 +837,25 @@
Is to do it in one statement ending with a semicolon:
-
-
-
+
struct Foo { int x; int y; } foo;
- |
+
Or to separate the two:
-
-
-
+
struct Foo { int x; int y; }; // note terminating ;
struct Foo foo;
- |
+
The D Way
Struct definitions and declarations can't be done in the same statement:
-
-
-
+
struct Foo { int x; int y; } // note there is no terminating ;
Foo foo;
- |
+
which means that the terminating ; can be dispensed with, eliminating the
confusing difference between struct {} and function & block {} in how semicolons
@@ -915,26 +869,22 @@
Naturally, another macro is used:
-
-
-
+
#include <stddef>
struct Foo { int x; int y; };
off = offsetof(Foo, y);
- |
+
The D Way
An offset is just another property:
-
-
-
+
struct Foo { int x; int y; }
off = Foo.y.offset;
- |
+
@@ -944,12 +894,10 @@
Unions are initialized using the "first member" rule:
-
-
-
+
union U { int a; long b; };
union U x = { 5 }; // initialize member 'a' to 5
- |
+
Adding union members or rearranging them can have disastrous consequences
for any initializers.
@@ -958,12 +906,10 @@
In D, which member is being initialized is mentioned explicitly:
-
-
-
+
union U { int a; long b; }
U x = { a:5 }
- |
+
avoiding the confusion and maintenance problems.
@@ -975,12 +921,10 @@
Members are initialized by their position within the {}'s:
-
-
-
+
struct S { int a; int b; };
struct S x = { 5, 3 };
- |
+
This isn't much of a problem with small structs, but when there
are numerous members, it becomes tedious to get the initializers
@@ -992,12 +936,10 @@
Member initialization can be done explicitly:
-
-
-
+
struct S { int a; int b; }
S x = { b:3, a:5 }
- |
+
The meaning is clear, and there no longer is a positional dependence.
@@ -1008,46 +950,36 @@
The C Way
C initializes array by positional dependence:
-
-
-
+
int a[3] = { 3,2,2 };
- |
+
Nested arrays may or may not have the { }:
-
-
-
+
int b[3][2] = { 2,3, {6,5}, 3,4 };
- |
+
The D Way
D does it by positional dependence too, but an index can be used as well:
The following all produce the same result:
-
-
-
+
int[3] a = [ 3, 2, 0 ];
int[3] a = [ 3, 2 ]; // unsupplied initializers are 0, just like in C
int[3] a = [ 2:0, 0:3, 1:2 ];
int[3] a = [ 2:0, 0:3, 2 ]; // if not supplied, the index is the
// previous one plus one.
- |
+
This can be handy if the array will be indexed by an enum, and the order of
enums may be changed or added to:
-
-
-
+
enum color { black, red, green }
int[3] c = [ black:3, green:2, red:5 ];
- |
+
Nested array initializations must be explicit:
-
-
-
+
int[2][3] b = [ [2,3], [6,5], [3,4] ];
int[2][3] b = [[2,6,3],[3,5,4]]; // error
- |
+
@@ -1056,40 +988,30 @@
The C Way
C has problems with the DOS file system because a \ is an escape in a string. To specifiy file c:\root\file.c:
-
-
-
+
char file[] = "c:\\root\\file.c";
- |
+
This gets even more unpleasant with regular expressions.
Consider the escape sequence to match a quoted string:
-
-
-
+
/"[^\\]*(\\.[^\\]*)*"/
- |
+
In C, this horror is expressed as:
-
-
-
+
char quoteString[] = "\"[^\\\\]*(\\\\.[^\\\\]*)*\"";
- |
+
The D Way
Within strings, it is WYSIWYG (what you see is what you get).
Escapes are in separate strings. So:
-
-
-
+
char[] file = 'c:\root\file.c';
char[] quoteString = \" r"[^\\]*(\\.[^\\]*)*" \";
- |
+
The famous hello world string becomes:
-
-
-
+
char[] hello = "hello world" \n;
- |
+
@@ -1100,30 +1022,24 @@
The C Way
C uses the wchar_t and the L prefix on strings:
-
-
-
+
#include <wchar.h>
char foo_ascii[] = "hello";
wchar_t foo_wchar[] = L"hello";
- |
+
Things get worse if code is written to be both ascii and wchar compatible.
A macro is used to switch strings from ascii to wchar:
-
-
-
+
#include <tchar.h>
tchar string[] = TEXT("hello");
- |
+
The D Way
The type of a string is determined by semantic analysis, so there is no need to wrap strings in a macro call:
-
-
-
+
char[] foo_ascii = "hello"; // string is taken to be ascii
wchar[] foo_wchar = "hello"; // string is taken to be wchar
- |
+
@@ -1132,18 +1048,14 @@
The C Way
Consider:
-
-
-
+
enum COLORS { red, blue, green, max };
char *cstring[max] = {"red", "blue", "green" };
- |
+
This is fairly easy to get right because the number of entries is small. But suppose it gets to be fairly large. Then it can get difficult to maintain correctly when new entries are added.
The D Way
-
-
-
+
enum COLORS { red, blue, green }
char[][COLORS.max + 1] cstring =
@@ -1152,7 +1064,7 @@
COLORS.blue : "blue",
COLORS.green : "green",
];
- |
+
Not perfect, but better.
@@ -1166,9 +1078,7 @@
a new type. The compiler doesn't distinguish between a typedef
and its underlying type.
-
-
-
+
typedef void *Handle;
void foo(void *);
void bar(Handle);
@@ -1176,14 +1086,12 @@
Handle h;
foo(h); // coding bug not caught
bar(h); // ok
- |
+
The C solution is to create a dummy struct whose sole
purpose is to get type checking and overloading on the new type.
-
-
-
+
struct Handle__ { void *value; }
typedef struct Handle__ *Handle;
void foo(void *);
@@ -1192,27 +1100,23 @@
Handle h;
foo(h); // syntax error
bar(h); // ok
- |
+
Having a default value for the type involves defining a macro,
a naming convention, and then pedantically following that convention:
-
-
-
+
#define HANDLE_INIT ((Handle)-1)
Handle h = HANDLE_INIT;
h = func();
if (h != HANDLE_INIT)
...
- |
+
For the struct solution, things get even more complex:
-
-
-
+
struct Handle__ HANDLE_INIT;
void init_handle() // call this function upon startup
@@ -1224,7 +1128,7 @@
h = func();
if (memcmp(&h,&HANDLE_INIT,sizeof(Handle)) != 0)
...
- |
+
There are 4 names to remember: Handle, HANDLE_INIT,
struct Handle__, value.
@@ -1233,9 +1137,7 @@
No need for idiomatic constructions like the above. Just write:
-
-
-
+
typedef void* Handle;
void foo(void*);
void bar(Handle);
@@ -1243,20 +1145,18 @@
Handle h;
foo(h);
bar(h);
- |
+
To handle a default value, add an initializer to the typedef,
and refer to it with the .init property:
-
-
-
+
typedef void* Handle = cast(void*)(-1);
Handle h;
h = func();
if (h != Handle.init)
...
- |
+
There's only one name to remember: Handle.
@@ -1268,27 +1168,23 @@
While C defines struct assignment in a simple, convenient manner:
-
-
-
+
struct A x, y;
...
x = y;
- |
+
it does not for struct comparisons. Hence, to compare two struct
instances for equality:
-
-
-
+
#include <string.h>
struct A x, y;
...
if (memcmp(&x, &y, sizeof(struct A)) == 0)
...
- |
+
Note the obtuseness of this, coupled with the lack of any kind
of help from the language with type checking.
@@ -1304,14 +1200,12 @@
D does it the obvious, straightforward way:
-
-
-
+
A x, y;
...
if (x == y)
...
- |
+
@@ -1320,14 +1214,12 @@
The C Way
The library function strcmp() is used:
-
-
-
+
char string[] = "hello";
if (strcmp(string, "betty") == 0) // do strings match?
...
- |
+
C uses 0 terminated strings, so the C way has an inherent
inefficiency in constantly scanning for the terminating 0.
@@ -1336,14 +1228,12 @@
Why not use the == operator?
-
-
-
+
char[] string = "hello";
if (string == "betty")
...
- |
+
D strings have the length stored separately from the string.
Thus, the implementation of string compares can be much faster
@@ -1353,14 +1243,12 @@
D supports comparison operators on strings, too:
-
-
-
+
char[] string = "hello";
if (string < "betty")
...
- |
+
which is useful for sorting/searching.
@@ -1372,9 +1260,7 @@
Although many C programmers tend to reimplmement bubble sorts
over and over, the right way to sort in C is to use qsort():
-
-
-
+
int compare(const void *p1, const void *p2)
{
type *t1 = (type *)p1;
@@ -1387,7 +1273,7 @@
...
qsort(array, sizeof(array)/sizeof(array[0]),
sizeof(array[0]), compare);
- |
+
A compare() must be written for each type, and much careful
typo-prone code needs to be written to make it work.
@@ -1397,13 +1283,11 @@
Sorting couldn't be easier:
-
-
-
+
type[] array;
...
array.sort; // sort array in-place
- |
+
@@ -1412,25 +1296,21 @@
To access volatile memory, such as shared memory
or memory mapped I/O, a pointer to volatile is created:
-
-
-
+
volatile int *p = address;
i = *p;
- |
+
The D Way
D has volatile as a statement type, not as a type modifier:
-
-
-
+
int* p = address;
volatile { i = *p; }
- |
+
@@ -1440,13 +1320,11 @@
String literals in C cannot span multiple lines, so to have
a block of text it is necessary to use \ line splicing:
-
-
-
+
"This text spans\n
multiple\n
lines\n"
- |
+
If there is a lot of text, this can wind up being tedious.
@@ -1454,14 +1332,12 @@
String literals can span multiple lines, as in:
-
-
-
+
"This text spans
multiple
lines
"
- |
+
So blocks of text can just be cut and pasted into the D
source.
@@ -1485,9 +1361,7 @@
some context outside of the trees, so a custom struct Paramblock
is created and a pointer to it is used to maximize efficiency.
-
-
-
+
struct Symbol
{ char *id;
struct Symbol *left;
@@ -1529,7 +1403,7 @@
}
return pb.sm;
}
- |
+
The D Way
@@ -1543,9 +1417,7 @@
The performance of the two versions is indistinguishable.
-
-
-
+
class Symbol
{ char[] id;
Symbol left;
@@ -1578,7 +1450,7 @@
}
return sm;
}
- |
+
@@ -1591,24 +1463,20 @@
integral type. To produce an unsigned right shift on an int,
a cast is necessary:
-
-
-
+
int i, j;
...
j = (unsigned)i >> 3;
- |
+
If i is an int, this works fine. But if i is
of a typedef'd type,
-
-
-
+
myint i, j;
...
j = (unsigned)i >> 3;
- |
+
and myint happens to be a long int, then the cast to
unsigned
@@ -1623,13 +1491,11 @@
do an unsigned right shift regardless of the sign of the left
operand. Hence,
-
-
-
+
myint i, j;
...
j = i >>> 3;
- |
+
avoids the unsafe cast and will work as expected with any integral
type.
@@ -1651,9 +1517,7 @@
class that holds an array of int's, and a user of that container
that computes the maximum of those int's.
-
-
-
+
struct Collection
{
int array[10];
@@ -1679,7 +1543,7 @@
c->apply(&max, comp_max);
}
- |
+
The C way makes heavy use of pointers and casting.
The casting is tedious, error prone, and loses all type safety.
@@ -1691,9 +1555,7 @@
and nested functions both to capture context
information and to improve locality.
-
-
- class Collection
+ class Collection
{
int[10] array;
@@ -1715,20 +1577,18 @@
}
c.apply(comp_max);
- } |
+ }
Pointers are eliminated, as well as casting and generic
pointers. The D version is fully type safe.
An alternate method in D makes use of function literals:
-
-
- void func(Collection c)
+ void func(Collection c)
{
int max = int.min;
c.apply(delegate(int i) { if (i > max) max = i; } );
- } |
+ }
eliminating the need to create irrelevant function names.
@@ -1741,9 +1601,7 @@
The C Way
-
-
-
+
#include <stdio.h>
#include <stdarg.h>
@@ -1768,7 +1626,7 @@
return 0;
}
- |
+
There are two problems with this. The first is that the
sum function needs to know how many arguments were
@@ -1787,9 +1645,7 @@
type, and the number of arguments becomes a property
of the array:
-
-
-
+
int sum(int[] values ...)
{
int s = 0;
@@ -1808,18 +1664,18 @@
return 0;
}
- |
+
+ |
