by copsarebastards on 3/9/2015, 4:44:42 AM
by cbd1984 on 3/8/2015, 11:11:52 PM
C is simple to compile into nearly-optimal code, or at least it was back in the 1970s, when computers had single-opcode dispatch or trivial pipelines, no SIMD hardware, no other parallelism worth mentioning, and it wasn't worth worrying about cache too much. (Running in the registers was a neater trick.)
That meant it was relatively simple to 'see' the assembly language 'behind' a given C function or stretch of code; it didn't take much to get inside the head of a C compiler, so you could be reasonably sure that a simple piece of C would result in a similarly simple piece of assembly out the other end.
That, of course, was well and good when it was reasonably simple to predict actual performance from glancing at assembly code, which assumes opcode performance (as opposed to, say, cache performance) dominates how fast the code runs.
Now... how many of those things still hold true on desktop and server class hardware?
by Moral_ on 3/8/2015, 9:35:48 PM
The first two invoke UB and are thus completely illogical.
by kazinator on 3/9/2015, 5:27:06 AM
I stopped reading after the explanations about return ((1 - sizeof(int)) >> 32);
Unless size_t is wider than 32 bits, it has undefined behavior. That's why it returns 0; it could as well be 42, or the program could terminate with or without a diagnostic message, etc.
by taeric on 3/8/2015, 11:09:10 PM
Who says simple things always yield simple results?
by agounaris on 3/8/2015, 10:09:44 PM
who said C is simple? :S
by dang on 3/8/2015, 8:53:40 PM
Can anybody figure out the year on this one? Internet Archive says 2011 but it seems it might be earlier.
by iopq on 3/9/2015, 5:21:53 AM
I've been looking for this for months, I wanted to link this to my friend who said he prefers C to Java for his CS classes.
All of the examples here are really horrible code. This is the second article in a few days on Hacker News to list out a few examples of how hard C is. And for little reason; there's absolutely no value in being able to write something like:
It probably has a bug, will be hard to debug, and isn't more performant than writing it in a clearer way. And unfortunately, while the examples here are probably all contrived, there are plenty of real-life cases where code as bad as this gets into production systems.So why are we still writing code like this?
The answer is reverse compatibility. Not just of compilers, but of tools and skillsets: people are unwilling to support multiple versions of C and want their code to run forever.
Objective-C and C++ do things to add functionality to C, but they don't remove the functionality of C that allows these kinds of problems.
This points to a need for a new language that avoids these issues. I think Rust is the answer, but I would like to see more languages try to fill that gap--competition is healthy.