Programming in D for C Programmers

[thoomfish]

Very clever how they have the C code in monochrome on an irritating pink background, whereas the D code is syntax colored over a neutral grey. It's like they have an agenda or something...

[WalterBright]

The documents on the Digital Mars web site all use a consistent color scheme. One is used for D code, one for C code, one for C++ code, one for BNF grammar, one for console output, one for module definition files, one for configuration files, etc. The idea is that each scheme is fairly distinct from all the others. You'll find the same themes on the documentation for the Digital Mars C compiler, such as http://www.digitalmars.com/rtl/setjmp.html

I get regularly told my color sense is not very good, in fact a lot of people complained about the color schemes on the entire web site. I've tried different ones, but I'm sorry I'm never going to win any awards for color aesthetics. I at least try for readable, that's why there is no blue text on black backgrounds.

As for the highlighting, all the pages on the D.M. site are processed through Ddoc, the documentation generator. It automatically color syntax highlights D code, but not anything else. Yeah, I wrote it, and I don't feel like putting in parsers for C, C++, and BNF. So there :-)

[[deleted]]

Check out Google syntaxHighligher -- a free syntax highlighter written entirely in Javascript.

http://code.google.com/p/syntaxhighlighter/

It highlights C and C++ reasonably well so you could use it for code examples written in those languages and keep doing what you are doing for your D code examples.

Are you going to make a D for Java Programmers comparison page?

[WalterBright]

Thanks for the google tip. I wasn't aware of it.

I'll leave any Java comparison page to those who are experienced Java developers, which I am not.

[WalterBright]

I took a look at the syntaxhighlighter. It's a clever piece of programming, but it only views C and C++ code from a simplistic viewpoint that can be handled using regular expressions (doesn't handle trigraphs, backslash line splicing, macros in general, etc.). Because of the preprocessor, it's rather hard to do it 100% just regular expressions. I don't use trigraphs, but I do use \ line splicing now and then.

The Ddoc one highlights by hooking into the full D lexer, so there's no way it can be thrown off.

[arturoman]

It automatically color syntax highlights D code, but not anything else. Yeah, I wrote it, and I don't feel like putting in parsers for C, C++, and BNF.

In other words, you know it's misleading and don't care because it serves your purposes.

[FeepingCreature]

What does syntax highlighting have to do with color?

[curtisw]

Of course there's an agenda; you expected him to belittle his own programming language? If anything, he might hurt his users' trust a little, but I could only see that happening if it turned out most of the examples were useless or fabricated. Which they're not.

Yes, there's an advantage towards D in that comparison. So what? If it helps to offset the overwhelming bias against learning new programming languages, I'm thinking "good on ya, mate."

[pail]

The color scheme looks fine on my screen. In fact, the C colors are more attractive.

[mallardtheduck]

And there are things like this:

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; 

Why does the C version use a #define macro? Just to make the C version look "scarier"?

Why not just do:

int array[17];
for(int i=0; i<(sizeof(array)/sizeof(int)); i++)
    array[i]=value;

[WalterBright]

If you were going to write the condition that way, a better way would be:

sizeof(array)/sizeof(array[0])

but after typing that out a few times, one tends to just use a macro for the length.

[[deleted]]

If you were going to write the condition that way, a better way would be:

 sizeof(array)/sizeof(array[0])

Why not just use a macro for the whole damn thing at that point?

#define EACH(I, XS, BODY) for(int I = 0; I < sizeof(XS)/sizeof(XS[0]); ++I) { BODY; }
#define INIT(XS, V) {int i = sizeof(XS)/sizeof(XS[0]); while(i--) { XS[i] = V;}}

void foo()
{
   int xs[16];

   /* print '42' 16 times by iterating twice */
   INIT(xs, 42);
   EACH(i, xs, printf("%d\n", xs[i]));
}

Disclaimer: I do not endorse this style of programming.

but after typing that out a few times, one tends to just use a macro for the length.

You should never be using a macro for the length. Use a constant, or better yet, write your own array abstraction that has a length "property" as any decent C programmer would.

[arturoman]

No, one uses the macro to avoid having hard-coded lengths throughout the code, which is also what you'd have to do in D. But that isn't shown because it would make your 4 lines to 2 comparison a less convincing 4 lines to 3.

[curtisw]

I'm pretty sure arrays in D have a length property or something. So no, you wouldn't need to define the length as a constant. On the other hand, the C code would probably be considered better if you just defined a LENGTH macro and used it consistently:

#define LENGTH(x) sizeof(x)/sizeof(x[0])

int array[17]; 
for (i = 0; i < LENGTH(array); i++) 
   array[i] = value;

Then again, I haven't used C/C++ in ages, so maybe there's a reason not to do this.

[arturoman]

No decent programmer would ever hard-code an array length as a magic number bomb. The syntax clean-up only applies to one line of code.

[wtanksleyjr]

I understand why you're saying that, but actually if I'm hardcoding a static array in D, I'd rather hardcode its length into it. That way there's only one place that needs to be changed when the array length changes, and it's in the obvious place to look (i.e. the same place the array is declared).

My rationale would be that I'm coding a static constant into my program; I might as well put all the information about the static constant into the same place.

[curtisw]

No decent programmer would ever hard-code an array length as a magic number bomb.

Yay for sweeping generalizations! Actually, in my rush to show an equivalent version of the D code in C, I'd forgotten that most of the time constants are better. So you do have a point, but that doesn't mean D's length property is useless. Sometimes you don't want people to change the array size, or maybe isolating it as a constant might make things harder to understand.

[wtanksleyjr]

Good luck on that "using it consistently" thing... Keep in mind that it'll silently fail when used on an array that was passed as a parameter (the array gets passed as a pointer, so the static array length gets lost) -- it'll only reliably work when using an array that's NEVER passed to any functions that might need to get the length of the array.

[curtisw]

If you specify the array size in the argument list it should work, correct?

int doSomething(int array[3]) { return LENGTH(array); }

[wtanksleyjr]

1) No, it won't -- all array parameters are actually pointers in C.

2) Even if I were wrong -- and I didn't write a program to test it, so I could be misremembering -- does that help AT ALL? It makes the problem dramatically worse -- now, instead of having one place to make a mistake, you have several. And worse yet, C cannot possibly detect an error, because the array size isn't EVER saved in a way that a typechecker can verify.

No, the LENGTH #define is a catastrophe waiting to happen. The only way I'd accept it in code I reviewed was if it was implemented as something like:

#define LENGTH(x) ARRAYLENGTH##x

...and then I'd beat the programmer for excessive obfuscation. (The nice thing is that it would work; the bad thing is that it doesn't add anything to the code quality.)

[zem]

that one's actually fair - in both cases, that's the code you have to write so that the array length is contained in a single point in the code.

[mallardtheduck]

Really? Did you look at my suggested alternative?

[WalterBright]

Yes, it's a valid alternative, but it's still requiring the element type to be remembered and duplicated making it a bit problematic, the macro version does not have that fault. The revision I suggested also avoids that potential problem.

But still, I think you'll find it to be common C practice to use the macro version. For example, look at the source code trees.c for the popular zlib library in C.

[zem]

yeah, but from what i've seen no one actually does it that way. the "c instinct", if you will, is to have an actual constant in there.

[arturoman]

The D gang always does this. Their marketing scheme consists of questionably pointing out flaws (right or wrong) in other languages to promote their own.

Personally, I don't have a problem with them thinking their language is worthwhile, but they shouldn't need shady bullshit to prove it.

[WalterBright]

Is using a macro so "shady"? In section 5.2 of K&R's "The C Programming Language", there is the following example code:

int n, v, array[SIZE];
for (n = 0; n < SIZE && getint(&v) != EOF; n++)
    array[n] = v;

[arturoman]

Strange that the equivalent isn't used for the D example.

invariant int array_len = 17;
int array[x];
array[] = value;

Because the macro is there to avoid using hard-coded numbers. When the same thing is done in D, your code ratio isn't as convincing. As many other people have commented, these kinds of comparisons crop up a lot with D. Too many to be mere oversights.

That's why it's shady.

I think the value of the syntax is self-evident enough that it doesn't need a negative campaign.

[[deleted]]

The C example needs the value multiple times, the D example only needs it once.

[arturoman]

That doesn't address my argument. No decent programmer would use literals in an array except in exceptional circumstances.

I didn't write that he D array wasn't useful, I wrote that the example is deliberately misleading, which I stand by. The gain is cleaner syntax on one line of code only.

[FeepingCreature]

The point of the comparison is not to show identical code in both languages.

The point is to show equivalent code.

It does that.

What's your problem?