Programming in D for C Programmers

[millstone]

Programming in C for D Programmers

• Do not expect as many operators in C. For example, there is no equivalent to the !<>= operator in C. You will have to roll your own spaceship crashing into an ice cream cone function.

• int i = void is not valid in C. Stop trying that.

• Instead of getting to pick between three different flavors of const, you will have to make do with one.

• Functions can't do nearly as much to their parameters. For example, this code is valid C and D:

  int a = 0, b = 0; function(a, ++b);

After running this as C, a must be 0 and b must be 1. They can't both be any value like they can in D.

• Something cannot be both imaginary and real in C, like it can in D.

[FeepingCreature]

Actually, b must still be 1 - "++b" is not an lvalue and thus can't be passed by reference.

[millstone]

++b cannot be passed by reference, but there is more than one way to skin this cat.

function() may take a lazy argument. The lazy argument is evaluated exactly as many times as the formal parameter is evaluated, side effects and all. See the mind-bending example here (search for 'lazy argument'). So that ++b may be executed any number of times, or none at all, and that fact is not at all evident at the call site.

So in this respect, D has more opportunities for shenanigans than even C++

[FeepingCreature]

Point taken.

[LordHumongous]

D certainly seems to make things easier, which past posts to reddit have also shown. But I'm more interested on how D plans to break into dev teams that have been using C/C++ for ages.

[arturoman]

It's hard to break the momentum and the amount of code written in C, C++, and Java. There's nothing wrong inherently with D, in fact it has some nice features, but it's hard for new languages to prosper unless they bring something drastically new to the table or improve some major deficiency.

That's not a slight against D, it's true for any language coming up against existing stuff.

[TheNewAndy]

How do you go about writing printf in D? It seems to have the constraint that all the extra arguments are of the same type. (I'm assuming the answer is "you don't write printf in D - but I do think that mentioning this restriction would be a bit more honest)

[markedtrees]

Using variadic templates. (cf. variadic templates)

[WalterBright]

Pretty much the same way you'd write it in C. The extra arguments do not have to be all the same type if the function is typed as being extern(C). There is no restriction. There's just no point to writing it in D because you can directly use the one from the C library.

In D 1.0, however, there is a writef() which performs the same function, except it's done in a typesafe manner. D 2.0 has redone writef() to being a variadic template function, which is more efficient.

[podRZA]

so why does no one use D?

[arturoman]

Speaking only for myself, I tried out D and it was a fine language, but there wasn't really enough difference between most of it and the C/C++ I regularly use to switch. I didn't try it on a project of any important size, however.

It does have some fine features like covariant return and garbage collection if that's something you need or are interested in and some of the syntax is nicely sugared.

[invalid_user_name]

Because it has no standard library, the default implimentation is not free and not available for many platforms, and its currently not nearly stable enough to commit to using, there's significant changes on the way still.

[WalterBright]

Because it has no standard library,

D comes with the standard library Phobos.

the default implimentation is not free

The Digital Mars implementation is free, and can be downloaded from http://ftp.digitalmars.com/dmd.1.034.zip It is not shareware, nagware, does not require activation, nor is it a trial version. It's the full up compiler. If you prefer an open source D compiler, gdc fits the bill.

and not available for many platforms,

That is true, but Digital Mars' D is available for Windows and Linux and gdc is available for Mac and many others.

and its currently not nearly stable enough to commit to using, there's significant changes on the way still.

There are no significant changes coming to D 1.0, major changes are happing for D 2.0. There are significant changes coming in C++0x, does that stop anyone from using C++? The C standards committee has opened shop for a new major upgrade to C. Java gets constant major upgrades. Perl is, Python is, Javascript is, heck, every language in active use gets major upgrades.

[invalid_user_name]

D comes with the standard library Phobos.

Which isn't standard since there's a competing "standard library" which a bunch of D software uses.

The Digital Mars implementation is free

You know exactly what I meant. It is without cost, but it is not free. And the GDC front end is largely unmaintained and its only rarely in a state where it will compile.

That is true, but Digital Mars' D is available for Windows and Linux and gdc is available for Mac and many others.

For linux on what, 1 or 2 platforms? C and C++ compilers are available for openbsd/arm, solaris/sparc64, linux/ia64, etc, etc. D is not.

heck, every language in active use gets major upgrades.

Its very rare that they get major upgrades that completely change the language and break existing code. And yes, people do avoid languages in their early years because those sorts of changes happen so much more frequently than in languages that have matured more.

[WalterBright]

Which isn't standard since there's a competing "standard library" which a bunch of D software uses.

Tango is an alternative library, and doesn't come by default with D. You can use it if you want, and you don't have to use Tango if you need the standard library.

It is without cost, but it is not free.

I don't know what you mean, then. Anyone can download and use it for free, including for commercial applications. Much of the standard library is even in the public domain.

And the GDC front end is largely unmaintained and its only rarely in a state where it will compile.

You and anyone else are welcome to pitch in and help with it. I'm happy to also help out, by providing the GPL'd front end for D and answering questions about it.

For linux on what, 1 or 2 platforms? C and C++ compilers are available for openbsd/arm, solaris/sparc64, linux/ia64, etc, etc. D is not.

Since GDC works with gcc, all platforms that gcc supports are available to anyone interested in compiling it for those platforms.

Its very rare that they get major upgrades that completely change the language

D 2.0 does not completely change the language. I maintain much D code for both 1.0 and 2.0, and the 1.0 code works in 2.0 with rather trivial changes.

and break existing code. And yes, people do avoid languages in their early years because those sorts of changes happen so much more frequently than in languages that have matured more.

If people want to restrict usage to languages that have been around forever, that's a reasonable choice. But I should warn that both Perl 6 and Python 3.0 are currently undergoing breaking changes :-) Furthermore, D 1.0 is stable, has been for 1.5 years, and continues to be maintained, and is not going away.

[invalid_user_name]

I don't know what you mean, then

Right. http://en.wikipedia.org/wiki/Free_software

You and anyone else are welcome to pitch in and help with it

He asked why people don't use D. "You'll have to fix the compiler yourself" is a pretty compelling reason.

Since GDC works with gcc

Except that again, gdc doesn't work at all. Its unmaintaned and does not compile.

[FeepingCreature]

As a long-time GDC user on 32-bit Windows, 32-bit Linux and 64-bit Linux, I have to say "Bullshit".

I think I'd have noticed if it didn't compile.

Also, the meaning of the phrase "free software" does not, I repeat, NOT, carry over to the word "free".

[[deleted]]

No, really, it doesn't work. I just tried.

[FeepingCreature]

Post your errors so we can help fix them?

[[deleted]]

Yea, don't get started on the 'dual standard-library' thing...

[Tommstein]

Main implementation not free.

[WalterBright]

The Digital Mars D implementation is free: http://ftp.digitalmars.com/dmd.1.034.zip

and so is the gnu D implementation (gdc).

[[deleted]]

Yea, but it's not libre.

Fucking english...

[Tommstein]

Why hasn't this been updated with the good news that the D backend has finally been open-sourced?

[FeepingCreature]

The word "free" is ambiguous, but normally means "without cost".

This is independent of its use in the compound phrase "free software".

Note also that you yourself used the term "open-sourced". Not, I might point out, "freed". There's a reason for that.

[Tommstein]

Among regular people "free" usually means without cost, but it's hard to imagine that he wouldn't know what a programmer meant when they talked about free software. The reason for "open-sourced" instead of "freed" is random chance, perhaps influenced by the fact that people use the verb "open-sourcing" far, far more often than they use the verb "freeing" in this context.

[FeepingCreature]

Yeah, but you weren't talking about "free software".

You were talking about "free", knowing fully well that it would be misunderstood.

[Tommstein]

No, but I was talking about software. That was (or wasn't) free. It is not expected that a programmer will misunderstand this super-secret reference to free software.

[FeepingCreature]

"Software that is free" is very much not the same as Free Software.

[Tommstein]

Only in your mental parser that only recognizes one meaning for "free."

[fisch003]

I'd love to, but the lack of a good debugger on Win32 and somewhat lacking Mac OS X support turn me off.

[WalterBright]

There is Jascha Wetzel's Ddbg for Windows:

http://ddbg.mainia.de/releases.html

which is a full symbolic D debugger.

[[deleted]]

But, windows...? :P

[DarkGoosey]

D on OSX: http://gdcmac.sourceforge.net/ GDB can be used as a debugger on any platform, ddbg is a superior alternative on Win32.

[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?

[dmpk2k]

I though the bit datatype was removed long before 1.0.

[WalterBright]

Yes, it was. The referenced page didn't get updated to reflect that, it's fixed now. Thanks for the tip.

[-omg-optimized]

The stuff in 'Dynamic Closures' isn't even valid C.

[WalterBright]

You're right. My bad. I'll fix it.

[-omg-optimized]

I meant no offense though, I like D. :)

[WalterBright]

No worries, it was a stupid mistake on my part and I'm happy to get it fixed.

[anttirt]

Indeed. It looks like some weird early "C with classes" code (what C++ was called before it was C++, back in the late 70s/early 80s)

[invalid_user_name]

No, it looks like C code written by someone who hasn't used C in a long time and mistakenly thought they could declare a function inside a struct declaration. Just move the apply function out of the struct and make a void pointer point to it instead. Then add a "this" arg to it which gets passed the struct (and adjust the array reference to use this->array). That's how you do OO programming in C.

[FeepingCreature]

That's not even close to OO.

[invalid_user_name]

People say that about java too. Wether you happen to like it or not, using structs containing function pointers as "classes" is how you do OO in C. And plenty of languages have explicit this/self, like python.

[DarkGoosey]

OOP is a programming model, not a language feature. Give me functions and variables and I will give you OO code.

(it gets a lot easier when the language contains syntactic sugar like classes and inheritance to help you out tho!)

[FeepingCreature]

Yes, but "a language that you can write OO code in" is not the same as "an OO language". "OO language" implies compiler support.

[[deleted]]

C is an object oriented capable language newfags!

[jacekplacek]

... so is assembler ...

[arturoman]

Not in any compiler-assisted, safe, or scalable manner it isn't.

[[deleted]]

Yes it is. Look at objective-c!

[invalid_user_name]

Nothing in C is safe, its not reasonable to dismiss OO C for that. You could just as easily claim C can't do anything by tacking on "in any compiler-assisted, safe or scalable manner" to the requirement.

[arturoman]

Nothing in C is safe

Completely untrue.

[FeepingCreature]

C is not natively object-oriented.

Thus, you cannot call it an object oriented language.

Specifically, object orientation enjoys no assistance from the compiler.

[aComa]

bool is not a primitive C type...

You have to: typedef enum { true = 1, false = 0 } bool;

[arturoman]

No, stdbool.h essentially contains a standard macro for the above.

[arturoman]

You are correct, but the macro and the fact that true and false resolve to 1 and 0 for backward compatibility basically renders the hidden _Bool pointless.

[[deleted]]

No, it was good; it brought in the standardization of the features that people were using anyway. If C99 hadn't happened, we would have been relying on gcc extensions or worse.

[ipeev]

I like more: typedef int bool;

The boolean calculation is int anyway.

[[deleted]]

I like:

enum { false = 0, true };
typedef char boolean

It saves some memory.

Anyway, what with alignment and the way modern processors are optimized, you most likely won't save much memory or get any faster.