The IOCCC Competition Is Back 201
Rui Lopes writes "After a 5 year hiatus, the IOCCC (International Obfuscated C Code Contest) is back! This marks the 20th edition of the contest. Submissions are open between 12-Nov-2011 11:00 UTC and 12-Jan-2012 12:12 UTC. Don't forget to check this year's rules and guidelines."
Re:It'd be nice if ... (Score:5, Informative)
Maybe I'm a little older than you think? :)
Re:The Internet is based on C (Score:4, Informative)
uint16_t x = 0;
int32_t y = 0;
Almost every platform I've ever worked on has stdint...
Re:The Internet is based on C (Score:5, Informative)
- I think people who put the "*" of pointer syntax near the variable name and not the type name when declaring pointers should be shot. It should always be int* pointer_to_int, not int *pointer_to_int.
I'm sure my complaints are unwarranted except for the first point.
But that's backwards of what the compiler really does. Consider this:
int* p, q;
What types do p and q have? p is a pointer-to-int; q is an int. By putting the * next to the type name it makes it look like all the things are int*, but they're not. By putting the * with the type (which I did for my first year of C coding) you're making reading the code harder rather than easier. It'd be like writing
a = b * c+d;
and trying to convey that the '+' binds tighter since it doesn't have spaces. That's not what the compiler will do and writing it so only serves to confuse the reader.
In addition, what you see at declaration is representative (modulo the weirdness of array subscript and pointer deference) to what you'd do to get the type. That is, int ***p means that you'd have to type ***p to get an int. *p means you'd need another ** to get an int, etc.
Re:It'd be nice if ... (Score:5, Informative)
Many common programming tasks require extensive pointer manipulation in C. Even the best programmers (I'm one of them, and I concede this point)
I'm seriously doubting your professed skill here. You don't ever have to do pointer arithmetic in C, unless you are counting parameter passing as 'extensive pointer manipulation,' but you pass parameters as pointers in Java too (that's why you can get an NPE). The most common use of pointer arithmetic is for array processing, but if you want to be safe you can just use the array[] notation and not worry about understanding pointer arithmetic (I usually do, unless I have a compelling need to use pointer arithmetic). Furthermore I don't even know what you are talking about when you say, "non-trivial function pointer." Aren't all function pointers the same, just a bunch of parameters and a return value? Or are you declaring an array of function pointers or something? That might be where your problems are coming from.
From experience I can say by far the thing that takes the most extra time when I am writing in C (compared to Java) is the lack of a good library, with common data structures like hash tables and lists and regular expressions. The number of times I've had to write a generic list library for some random platform, or figure out someone else's nonstandard implementation, is depressing.
Also the generics in Java are a double edged sword. They allow more flexibility, but allow you to get away with writing incredibly confusing code, that can be extremely difficult to understand without a debugger. C code (really) tends to be a lot more readable. The downside is that it's usually a lot easier to refactor Java code without needing to rewrite a lot of interfaces (even when the interfaces were poorly written in the first place).
Ultimately though, a good programmer will write good code in any language. A poor programmer will likewise write poor code in any language.