spir:
> As a way to start learning D by practicing, I'm trying to implement a symbol
> table as linked list: see prototype code of the structs below. (Hints about
> good D coding welcome :-)
I have modified your code a little:
struct Symbol {
string name;
int element;
Symbol* next;
this(string n, int e, Symbol* s=null) {
name = n;
element = e;
next = s;
}
}
struct List {
Symbol* first;
int element(string name) {
for (auto symbol = this.first; symbol != null; symbol = symbol.next)
if (symbol.name == name)
return symbol.element;
return 0;
}
}
void main() {
auto l = List(new Symbol("baz", 3, new Symbol("bar", 2, new Symbol("foo",
1))));
assert(l.element("bar") == 2);
}
- There's no need to initialize int to 0, string to "", pointers to null, etc,
the compiler does it for you on default. Each type has a default init value
(for floating point values it uses a NaN).
- Generally don't put a space before the ending semicolon.
- Four spaces indent and no space before the "*" of the pointer, as you have
done, is OK.
- Using a while loop as you have done is OK, I have used a for loop just to
show a shorter alternative.
- It's generally better to put one or two blank lines before structs,
functions, etc
- (*symbol).name is written symbol.name in D.
- After an { generally a \n is used, there's no need to use the ; after the }
- using 0 as error return value is sometimes OK, but also keep in mind that
exceptions are present.
- while(symbol) is acceptable, but some people prefer to put an explicit
comparison to make the code more readable.
- sometimes using "auto" helps.
- In D linked lists are doable, but much less used, think about using a dynamic
array, or even in this case an associative array:
void main() {
auto aa = ["foo": 1, "bar": 2, "baz": 3];
assert(aa["bar"] == 2);
}
> 1. To please the compiler, I had to wrap dereferencing in parens, like in
> "(*symbol).name". Is this just normal (for disambiguation)?
> 2. Just noticed the compiler accepts "symbol.name", while symbol is a
> pointer: is there implicit dereferencing of pointers to structs? If yes, does
> this also apply to pointers to arrays (for information, this what Oberon
> does).
Generally the field dereferencing doesn't require the "(*symbol).name", in D
you use "symbol.name".
Pointers to arrays are possible, but quite uncommon in D.
> And a note: had forgotten to add an empty main(), just for compiling: the
> linker produced a rather big amount of error text without any hint to the
> actual issue. Maybe dmd could cope with that before calling gcc?
I agree, I have bug report 4680 open on something similar:
http://d.puremagic.com/issues/show_bug.cgi?id=4680
> Finally: the reference is rather harsh for me, esp there are very few example
> (I have few practice of C, and none of C++); the bits of tutorials I found
> are too light or just started (toc points to empty pages). Is there anywhere
> online a kind of D programming guide, even not polished or possibly
> unfinished (I know about the book; maybe I'll order it, but in meantime...).
The D2 documentation isn't abundant yet :-)
Bye,
bearophile
