The IOCCC Competition Is Back

← Back to Stories (view on slashdot.org)

The IOCCC Competition Is Back

Posted by samzenpus on Sunday November 13, 2011 @06:22AM from the welcome-back dept.

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."

201 comments

Min score:

Reason:

Sort:

It'd be nice if ... by fsckmnky · 2011-11-13 06:25 · Score: 5, Insightful

They created a competition for the most well structured, well documented, clean and correct code.

Most C coders seem to achieve obfuscation without any additional incentive.
1. Re:It'd be nice if ... by phantomfive · 2011-11-13 06:27 · Score: 5, Interesting
 
 But then we never would have a piece of code that calculates its own area. Isn't that worth it? (LINK).
 
 --
 "First they came for the slanderers and i said nothing."
2. Re:It'd be nice if ... by masternerdguy · 2011-11-13 06:35 · Score: 5, Insightful
 
 This is a good competition because it helps exploit the guts of C in new and exciting ways. Go back to your clean and neat database client if you can't play with the cowboys.
 
 --
 To offset political mods, replace Flamebait with Insightful.
3. Re:It'd be nice if ... by Hazel+Bergeron · 2011-11-13 06:37 · Score: 5, Insightful
 
 Most C coders seem to achieve obfuscation without any additional incentive.
 Nonsense. C is simple and, while some smart programmers think it's necessary to over-use the preprocessor (even the Linux kernel is sometimes guilty), it's a language you can learn once and apply productively for the rest of your life.
 Contrast this with the ten dozen other fly-by-night half-baked languages which have flooded the marketplace over the past year, each with their uninteresting quirks of syntactic sugar, competing on the basis of some uniquely uninteresting difference which can almost always be trivially implemented in any of the alternatives. They are hard to read in the same way that German is hard to read to someone who has only been reading German for a year: skill and speed comes through practice with the language, not from the ego of its authors.
4. Re:It'd be nice if ... by masternerdguy · 2011-11-13 06:38 · Score: 0
 
 Contrast this with the ten dozen other fly-by-night half-baked languages which have flooded the marketplace over the past year, each with their uninteresting quirks of syntactic sugar
 *cough* python *cough*
 
 --
 To offset political mods, replace Flamebait with Insightful.
5. Re:It'd be nice if ... by wisnoskij · 2011-11-13 06:41 · Score: 1
 
 It is called playing to your strengths.
 While producing well structured, well documented, clean and correct code in C would be quite a challenge it could never approach some of the new languages in these terms.
 
 --
 Troll is not a replacement for I disagree.
6. Re:It'd be nice if ... by Anonymous Coward · 2011-11-13 06:42 · Score: 5, Funny
 
 Yeah, Python sure flooded the marketplace in the past year. Now, if you'll excuse me, I've got to check the breaking news about the Lewinsky scandal after buying some hot dot-com stocks while on the way to work at the World Trade Center because apparently it's the late nineties again somehow.
7. Re:It'd be nice if ... by Anonymous Coward · 2011-11-13 06:46 · Score: 5, Insightful
 
 Nonsense. C is simple and, while some smart programmers think it's necessary to over-use the preprocessor (even the Linux kernel is sometimes guilty), it's a language you can learn once and apply productively for the rest of your life.
 Contrast this with the ten dozen other fly-by-night half-baked languages which have flooded the marketplace over the past year, each with their uninteresting quirks of syntactic sugar, competing on the basis of some uniquely uninteresting difference which can almost always be trivially implemented in any of the alternatives. They are hard to read in the same way that German is hard to read to someone who has only been reading German for a year: skill and speed comes through practice with the language, not from the ego of its authors.
 +1, it all started going downhill when :
 - professional language designers abdicated their role, and the void was filled by amateurs
 - people who use these languages have no fucking clue what they're doing and we're all paying the price
 - corporations hyped languages for their own purposes and languages stagnated or worse were crapified to an absurd level (witness java).
8. Re:It'd be nice if ... by Rosco+P.+Coltrane · 2011-11-13 06:51 · Score: 4, Interesting
 
 Most C coders seem to achieve obfuscation without any additional incentive.
 You got it wrong: bad coders create bad code. Good coders know how to create good code. In any language.
 When someone knows C well enough to create a truly obfuscated or compressed piece of portable C code that follows the rule of the language to a tee, i.e. that can be compiled strict or linted, and wins the IOCCC, it's a very good sign that this someone can create excellent C code.
 I should know, I won the IOCCC years ago, and used it many times in my resume. When would-be employers told me "what's the IOCCC?", I knew they weren't going to be good employers. When they told me "oh, I see you won the IOCCC", they knew I could code good C, and I knew they groked what I did. Winning the IOCCC helped me land a job a few times.
 
 --
 "A door is what a dog is perpetually on the wrong side of" - Ogden Nash
9. Re:It'd be nice if ... by sgt+scrub · 2011-11-13 06:53 · Score: 1
 
 They did. It failed. They are back to what comes naturally, Erlang. :p
 
 --
 Having to work for a living is the root of all evil.
10. Re:It'd be nice if ... by tgv · 2011-11-13 06:54 · Score: 3, Insightful
 
 Sure, that could be nice as well, but the IOCCC provides great challenges and puzzles, something that a clean code contest wouldn't. And what would you rather see in your news paper: difficult puzzles or easy ones? Or, for the youngsters here: would you rather play word feud, or type the answer to 1 + 1 over and over again?
 Besides that, the IOCCC entries contain mostly well structured and correct code, and afterwards they get documented as well. It's just not readable.
11. Re:It'd be nice if ... by 93+Escort+Wagon · 2011-11-13 06:59 · Score: 3, Funny
 
 Nonsense. C is simple and, while some smart programmers think it's necessary to over-use the preprocessor (even the Linux kernel is sometimes guilty), it's a language you can learn once and apply productively for the rest of your life.
 Contrast this with the ten dozen other fly-by-night half-baked languages which have flooded the marketplace over the past year, each with their uninteresting quirks of syntactic sugar, competing on the basis of some uniquely uninteresting difference which can almost always be trivially implemented in any of the alternatives. They are hard to read in the same way that German is hard to read to someone who has only been reading German for a year: skill and speed comes through practice with the language, not from the ego of its authors.
 Wow! Dr. Ritchie, everyone thought you were dead!
 
 --
 #DeleteChrome
12. Re:It'd be nice if ... by Khyber · 2011-11-13 07:10 · Score: 2
 
 Go look up the Demoscene.
 
 --
 Still waiting on Serviscope_minor to wake up to fucking reality and realize that Jessica Price isn't going to fuck him.
13. Re:It'd be nice if ... by Anonymous Coward · 2011-11-13 07:13 · Score: 4, Insightful
 
 Closed source code is the same, only you don't get to see it.
14. Re:It'd be nice if ... by Anonymous Coward · 2011-11-13 07:25 · Score: 2, Insightful
 
 I'm going to say that open source is bad and pre-emptively brand all disagreement as fanboyism so that my opinion is taken as authoritative.
 FTFY
15. Re:It'd be nice if ... by Rosco+P.+Coltrane · 2011-11-13 07:37 · Score: 4, Informative
 
 Maybe I'm a little older than you think? :)
 
 --
 "A door is what a dog is perpetually on the wrong side of" - Ogden Nash
16. Re:It'd be nice if ... by Ethanol-fueled · 2011-11-13 07:40 · Score: 1, Troll
 
 ...it all started going downhill when...professional language designers abdicated their role, and the void was filled by amateurs...people who use these languages have no fucking clue what they're doing and we're all paying the price...
 No, it started when we had to take over your obfuscated crap which is technically C but most resembles the bastard love-child of BASIC and assember, you know, the stuff with variable and type names like "__MfxVge__" you didn't bother to comment because you wanted to artificially inflate your worth? The kind of crap that would be easier to rewrite than refactor?
 
 Your job security is my job security - Only your code will be forever locked in a vault and replaced with mine, which will live on because I know how to write comments and spell out complete words.
17. Re:It'd be nice if ... by Anonymous Coward · 2011-11-13 07:47 · Score: 0
 
 I should know, I won the IOCCC years ago, and used it many times in my resume. When would-be employers told me "what's the IOCCC?", I knew they weren't going to be good employers. When they told me "oh, I see you won the IOCCC", they knew I could code good C, and I knew they groked what I did. Winning the IOCCC helped me land a job a few times.
 Alas, apparently it didn't help so much in keeping them.
18. Re:It'd be nice if ... by gomiam · 2011-11-13 07:49 · Score: 2
 
 You can sigh all you want. Lousy programmers will write lousy code whether it is open source or not, whether it is C or not. I know, I have had to maintain it (and certainly written it at some time). Just sprinkle ten or so non-named constants in your code to signal for some database offsets and you are in for a few entertaining hours/days of repurposing.
19. Re:It'd be nice if ... by Goaway · 2011-11-13 08:01 · Score: 2
 
 Let me tell you, no demo code is ever anywhere near well structured, well documented, clean or correct.
20. Re:It'd be nice if ... by petes_PoV · 2011-11-13 08:13 · Score: 4, Insightful
 
 Nonsense. C is simple and, while some smart programmers think it's necessary to over-use the preprocessor (even the Linux kernel is sometimes guilty), it's a language you can learn once and apply productively for the rest of your life.
 Contrast this with the ten dozen other fly-by-night half-baked languages which have flooded the marketplace over the past year.
 This clearly shows you simply don't understand the problem. A good programmer can (and does) write well structured, clean, DOCUMENTED and maintainable product in any language. The issue has nothing to do with the language used and everything to do with lack of discipline, inexperience and a slapdash and unprofessional attitude. Usually the worst programmers are the ones who think that once the code is written and compiles clean, the job is done. For most of these people there is little hope of educating them as they are incapable of seeing the bigger picture.
 
 --
 politicians are like babies' nappies: they should both be changed regularly and for the same reasons
21. Re:It'd be nice if ... by Hazel+Bergeron · 2011-11-13 08:30 · Score: 1
 
 Yes, a true communicator switches to any of Earth's languages at will and celebrates the variety, eagerly perfecting his ability in any new language which some committee or group of enthusiasts recently invented. This is a realisable and good use of the copious time every human has available: the sugary topping has always been more important than the meal below.
22. Re:It'd be nice if ... by TheCouchPotatoFamine · 2011-11-13 08:33 · Score: 1
 
 RIGHT the fuck on. +5, bigup, the facts of life.... here gentlemen - you have your answer.
 
 --
 CS majors know the time/space tradeoff, but they never get taught the 3rd, crucial, tradeoff of the set: comprehension!
23. Re:It'd be nice if ... by Anonymous Coward · 2011-11-13 08:40 · Score: 0, Insightful
 
 Wow, way not to look at all like a giant douchebag.
24. Re:It'd be nice if ... by Anonymous Coward · 2011-11-13 08:59 · Score: 0
 
 as a gunsmith?
 seriously, congratulations!
25. Re:It'd be nice if ... by wavedeform · 2011-11-13 09:15 · Score: 2
 
 You got it wrong: bad coders create bad code. Good coders know how to create good code. In any language.
 My favorite programming adage: "You can create bad Fortran in any language."
26. Re:It'd be nice if ... by Anonymous Coward · 2011-11-13 09:18 · Score: 0
 
 Are you sure you don't mean C++?
27. Re:It'd be nice if ... by Khyber · 2011-11-13 09:20 · Score: 1
 
 Are you serious?
 It's so clean and correct that you can put a near doom-3 graphics game in 96K of executable code. Ever seen .kkreiger?
 
 --
 Still waiting on Serviscope_minor to wake up to fucking reality and realize that Jessica Price isn't going to fuck him.
28. Re:It'd be nice if ... by martin-boundary · 2011-11-13 09:38 · Score: 3, Funny
 
 Great Scott! You're in a TIME LOOP! Don't move! There's a car to your left, get in slowly and accelerate to 88mph down the street. Oh, and here's a banana peel for the FUSION REACTOR.
29. Re:It'd be nice if ... by shagie · 2011-11-13 09:43 · Score: 2
 
 Pardon me, but are you serious? Claiming that code is clean (or correct) because it compiles to a small executable isn't necessarily true. The demo scene prides itself on small executables and optimizes for this. Such optimizations are rarely the product of clean and correct code but rather hand crafted dark compiler (or assembler) magic.
30. Re:It'd be nice if ... by Anonymous Coward · 2011-11-13 09:51 · Score: 0
 
 Hmm.. http://en.wikipedia.org/wiki/Sheriff_Rosco_P._Coltrane
31. Re:It'd be nice if ... by Anonymous Coward · 2011-11-13 09:52 · Score: 0
 
 I have no problem with his non-bloatful statement; it's not self-serving in any way or big headed.
 I'm not trying to be demeaning, but good C code looks obfuscated to the less skilled. How many
 if - do constructs do you use in your c-code, or if - for loops? The coma operator? Macros?
 Throw stones after you even enter the IOCCC let alone win.
32. Re:It'd be nice if ... by Anonymous Coward · 2011-11-13 09:56 · Score: 4, Interesting
 
 You're making basically the same argument as people were saying back when machine code was what people wrote and C was new. If you have an open mind, you can easily see that C has serious shortcomings by modern language standards.
 C offers no abstractions for complex data types. It offers no subtyping. There's no facility for generic programming other than macros, which everyone knows suck. No support for closures or comprehensions. None of these things are "trivially implemented", as you state. Even its syntax sucks, as anyone would agree who's tried to declare a non-trivial function pointer.
 Many common programming tasks require extensive pointer manipulation in C. Even the best programmers (I'm one of them, and I concede this point) make ocassional mistakes with pointers, and they are the worst kind of bug: silently incorrect or a crash at a random place in the code.
 C is perfectly appropriate for some projects, especially with really low-level code (as most C constructs translate directly to assembly). C++ is usually better, as it has a richer typing system and ability to do generic programming, but you need to be an expert as the language is full of pitfalls (which are mostly C's fault). For projects that don't need to be close to the hardware, scripting languages can multiply programmer productivity.
33. Re:It'd be nice if ... by Surt · 2011-11-13 10:01 · Score: 1
 
 But no one wants that, and hence, Microsoft.
 
 --
 "Who is the Journal of Quantum Physics going to believe?" --Stephen Hawking
34. Re:It'd be nice if ... by Joce640k · 2011-11-13 10:31 · Score: 2
 
 Nonsense. C is simple and, while some smart programmers think it's necessary to over-use the preprocessor (even the Linux kernel is sometimes guilty), it's a language you can learn once and apply productively for the rest of your life.
 An upgrade to C++ is a very good idea though.
 
 --
 No sig today...
35. Re:It'd be nice if ... by Anonymous Coward · 2011-11-13 10:37 · Score: 0
 
 Did you mean C++?
 I've used C throughout my professional career and even the worst code is still quite legible after running it through pretty printing to standardize the formatting.
 C++ code can be an absolute mess.
36. Re:It'd be nice if ... by fsckmnky · 2011-11-13 11:01 · Score: 0
 
 If I dare to clarify C or C++ ... it will only result in exponential flamage, thus, I leave it open to interpretation.
37. Re:It'd be nice if ... by gomiam · 2011-11-13 11:14 · Score: 3, Funny
 
 I would suggest you take up dubbing the Twilight movie series. You seem to have half their dialogues pat down.
 Back on track, do you have anything useful to add besides pining for the fjords?
38. Re:It'd be nice if ... by antifoidulus · 2011-11-13 11:23 · Score: 3, Insightful
 
 while some smart programmers think it's necessary to over-use the preprocessor
 
 And that is ultimately my main beef with C, it's impossible to write non-trivial code that DOESNT make use of the pre-processor. Header guards in 2011? Really? C either needs to make an Objective-c like import statement a standard or else make #pragma once standard and make it default, so that if in the rare case you do actually need to include a file more than once, THEN you have to use a pre-processor command. I think the pre-processor is a really useful feature of C, but it should never be essentially mandatory to use it.
 
 --
 Monstar L
39. Re:It'd be nice if ... by Anonymous Coward · 2011-11-13 11:27 · Score: 2
 
 I would hope that no one who actually knows what they're doing would ever create a type with the name __MfxVge__, because symbols starting with a leading double underscore are reserved for use by the implementation. You knew that right? Right? Obviously, because you know how to write comments and spell out complete words.
40. Re:It'd be nice if ... by Goaway · 2011-11-13 12:25 · Score: 1
 
 Heh.
 Let me tell you, you don't get to 96k by writing clean code. You get there by writing utter unholy messes, and you get there by cheating like hell, and you get there by using every dirty trick in the book.
 Also, you often do it in a week or so before the compo, and continue right up to the deadline, in the party hall, and you do it know you will never have to maintain or look at that code ever again after you hand it in.
 If you think demoscene code is "clean", you have absolutely zero experience with it.
41. Re:It'd be nice if ... by Khyber · 2011-11-13 12:31 · Score: 2
 
 Considering I have done some demos myself, you'd be wrong.
 The software running my entire research facility is in 4K, that's network stack, video feed controls, nutrient/water monitoring, the works.
 You don't get good small executables writing crappy code.
 Period.
 
 --
 Still waiting on Serviscope_minor to wake up to fucking reality and realize that Jessica Price isn't going to fuck him.
42. Re:It'd be nice if ... by Goaway · 2011-11-13 12:42 · Score: 1
 
 Considering I have done some demos myself, you'd be wrong.
 Links?
 
 The software running my entire research facility is in 4K, that's network stack, video feed controls, nutrient/water monitoring, the works.
 That is code that you are going to be maintaining. That is absolutely nothing like demo code.
43. Re:It'd be nice if ... by Anonymous Coward · 2011-11-13 12:45 · Score: 2, Insightful
 
 While your code may be technically correct, compile, and do what it's intended to do, that does not make it good code. It just makes it code that works.
 Look at IOCCC examples posted on wikipedia. If the average programmer (ie: your coworker) will need to spend more time thinking about the extra whitespace and the syntactic monstrosity that comprises the competition, then your code design sucks and you've ended up causing more headaches with your "good" code.
44. Re:It'd be nice if ... by Anonymous Coward · 2011-11-13 13:22 · Score: 0
 
 agreed, they are promoting bad behavior
45. Re:It'd be nice if ... by Anonymous Coward · 2011-11-13 13:56 · Score: 0
 
 They created a competition for APL or APL2, which can be so clean it's unreadable (to some).
46. Re:It'd be nice if ... by syousef · 2011-11-13 15:31 · Score: 1
 
 Nonsense. C is simple and, while some smart programmers think it's necessary to over-use the preprocessor (even the Linux kernel is sometimes guilty), it's a language you can learn once and apply productively for the rest of your life.
 An upgrade to C++ is a very good idea though.
 I know, let's call it C# or maybe Java.
 
 --
 These posts express my own personal views, not those of my employer
47. Re:It'd be nice if ... by stanlyb · 2011-11-13 16:04 · Score: 2
 
 If you sometimes made some mistakes with pointers, occasionally, it is 10000 times better than what an unexperienced C# developer could do with all the neat language features, you simply have no idea how obfuscated his code could become, and how much you begin to like the idea of having revoked the death penalty...
48. Re:It'd be nice if ... by T-Bone-T · 2011-11-13 16:18 · Score: 1
 
 I'm not very familiar with this competition but that seems to be the very point. The winning code should be almost impossible to understand unless you are very good. This isn't good code in the traditional sense but in an ironic sense.
49. Re:It'd be nice if ... by Austerity+Empowers · 2011-11-13 16:53 · Score: 3, Funny
 
 Java is NOT an upgrade to C++. There was a fork in the road, to the left went C++ to the right went Java. C++ took you through a swamp filled with poisonous snakes, quicksand and man eating spiders. Java took you through a haunted forest, with werewolves and zombies.
 No matter which path you took, you died before reaching your goal.
50. Re:It'd be nice if ... by syousef · 2011-11-13 16:58 · Score: 1
 
 Java is NOT an upgrade to C++. There was a fork in the road, to the left went C++ to the right went Java. C++ took you through a swamp filled with poisonous snakes, quicksand and man eating spiders. Java took you through a haunted forest, with werewolves and zombies.
 No matter which path you took, you died before reaching your goal.
 Java's got it's weaknesses but there's nothing seriously wrong with the language. The problem is the libraries, especially the enterprise libraries, and I mean both the EJB monstrosity and the consultant hell that passes for light weight. Misuse of the idea of design patterns are to blame. Let's look for ways to tack on another layer of abstraction we'll never actually use, shall we?
 
 --
 These posts express my own personal views, not those of my employer
51. Re:It'd be nice if ... by phantomfive · 2011-11-13 17:40 · 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.
 
 --
 "First they came for the slanderers and i said nothing."
52. Re:It'd be nice if ... by TangoMargarine · 2011-11-13 18:06 · Score: 1
 
 Even the best programmers (I'm one of them, and I concede this point) make ocassional mistakes
 Heh.
 
 --
 Unity? Screw that: XFCE. Slashdot Beta? Screw that: SoylentNews. Australis? Screw that: Pale Moon. UX developers DIAF
53. Re:It'd be nice if ... by bertok · 2011-11-13 18:57 · Score: 2
 
 Sounds great, but all that nice sounding theory doesn't apply in practice. For example, C and C++ in particular are languages that started out "simple" but became quagmires over time. It's impossible to write portable C/C++ code that meets your requirements of "well structured and clean".
 Haven't you noticed how every cross-platform C/C++ library starts out with pages of pages of "MY_LIBRARY_INT32" and "MY_LIBRARY_EXPORT" and other redefinitions of "standard" types, keywords, and functions? That's because C is a badly designed language where the behaviour and/or availability of even basic language keywords like "int" is a crap shoot that depends on the compiler and the target processor type. This then makes each library wonderfully unique and special, with their own macros to paper over this inconsistency.
 Compare this to, say, C# or Java, where "int" is always exactly 32 bits and signed, no matter what. This means that if I pick up some random library off the web for some obscure purpose, it just works, and I'm don't have to figure out what the "int" type really means, or if it'll match the "int" type in some other library. I could go on about how every C library needs to redefine such basic concepts as memory allocation, or has a unique and special way of handling buffers or streams -- I'm sure you get the idea. No matter how skilled a programmer is, they will end up having to do the same kind of thing, because the language provides no real alternative, and the standard library is very small, and not very standard.
 I recently had to pick up a C compression library, which had a simplified version for users who "didn't need all the fancy features of the full version". It had a 50KB header file, 99% of which platform-detection, followed by... five actual function definitions. Three of those were for memory management -- because everything needs that to be reinvented, clearly. How is this "clean"? What would you do to make this "clean", without dropping cross-platform support?
 Meanwhile, this Java code will work on all platforms, processors, and compilers, forever and ever:
 public class Compressor {
 public byte[] compress( byte[] data ) { ... }
 public byte[] decompress( byte[] data ) { ... }
 }
 A tad "cleaner" than 50KB of macros, don't you think?
54. Re:It'd be nice if ... by complexpolygon · 2011-11-13 19:36 · Score: 0
 
 > I should know, I won the IOCCC years ago, and used it many times in my resume.
 Odd. There is no Rosco P. Coltrane listed on the winners page: http://www.ioccc.org/winners.html
 Either you lied, your name isn't Rosco P. Coltrane or you were an anonymous submitter.
55. Re:It'd be nice if ... by Khyber · 2011-11-13 19:44 · Score: 1
 
 No, I am not maintaining it, in fact it is one-off.
 The demos I have done are all for specific hardware in embedded platforms, not x86 machines.
 
 --
 Still waiting on Serviscope_minor to wake up to fucking reality and realize that Jessica Price isn't going to fuck him.
56. Re:It'd be nice if ... by PeterBrett · 2011-11-13 20:43 · Score: 2
 
 Meanwhile, this Java code will work on all platforms, processors, and compilers, forever and ever:
 I'll switch to using a language other than C when a language other than C allows me to use wait-free shared-memory multiprocessing algorithms.
 
 --
 Pirate Party UK
57. Re:It'd be nice if ... by PeterBrett · 2011-11-13 20:46 · Score: 1
 
 "#pragma once" is broken.
 
 --
 Pirate Party UK
58. Re:It'd be nice if ... by JasterBobaMereel · 2011-11-13 20:52 · Score: 2
 
 IOCCC code is hard to read
 DemoScene code is efficient
 Both are normal code taken to extremes
 
 --
 Puteulanus fenestra mortis
59. Re:It'd be nice if ... by fatphil · 2011-11-13 20:52 · Score: 1
 
 No serious flaws? So you're too high on koolaid to remember
 http://thedailywtf.com/Articles/The-Integer-Cache.aspx
 And it seems that you need a string builder class to help you manipulate strings. Sorry, but that tells me that you're doing strings wrong.
 
 But apart from the integers and the strings, everything's fine.
 
 --
 Also FatPhil on SoylentNews, id 863
60. Re:It'd be nice if ... by Anonymous Coward · 2011-11-13 20:59 · Score: 0
 
 I represent your electricity provider. We can see no contracts with, or payments from, a "complexpolygon", and therefore you are stealing our electricity. Please turn off your computer immediately.
61. Re:It'd be nice if ... by minus9 · 2011-11-13 21:01 · Score: 1
 
 Looks like those Duke boys have got the sheriff in a whole mess o' trouble.
62. Re:It'd be nice if ... by Jerome+H · 2011-11-13 21:45 · Score: 1
 
 And yet you fail to give an accurate example of something that breaks on multiple platforms because "char" is probably the most stable type in C.
 And btw in C you have intXX_t and uintXX_t types now.
 
 --
 int main() { while(1) fork(); }
63. Re:It'd be nice if ... by bertok · 2011-11-13 21:55 · Score: 1
 
 C# and Java both have atomic operations in the standard library. See Interlocked.CompareExchange, and java.util.concurrent.atomic for examples.
 Multi-threaded programming is particularly easy in those languages, because a lot of their internals are inherently thread-safe. For example, strings are read-only, so they can be passed around risk free. Similarly, mark & sweep garbage collection is thread-safe, and doesn't suffer from the rare but complex to debug memory leaks that occur with reference counting. It's also faster -- there's garbage collectors in common use now in the Java world that significantly outperform malloc. Throw in the overheads of atomic increment/decrement required for thread-safe reference counting in the C/C++ world, and suddenly things can tip towards Java in a big way.
 I do C# mostly myself, and I've found that because it makes multi-threading so easy and safe (compared to C/C++), that I use it much more often than I would otherwise. Even if it's a tad slower than C, the ability to liberally sprinkle multi threading throughout the code makes the end result a lot more parallel, and hence overall faster or more responsive.
 Take a look at the new await and async keywords about to be added to .NET v4.5. They allow traditional serial code to be converted to a thread-pooled asynchronous version with what amounts to about two dozen additonal characters of code!
 Meanwhile, C and C++ have poor support for multi-threading, especially if code needs to be portable. There's basically no threading standard library to speak of, or even a threading aware memory model!
64. Re:It'd be nice if ... by PeterBrett · 2011-11-13 21:57 · Score: 1
 
 I was talking about multiprocessing, not multithreading.
 
 --
 Pirate Party UK
65. Re:It'd be nice if ... by shutdown+-p+now · 2011-11-13 22:03 · Score: 1
 
 professional language designers abdicated their role, and the void was filled by amateurs
 I'm not sure how you define a "professional language designer", but I don't think Ritchie was one either way. It's precisely why there are a lot of messy things about the original design of C, such as its declarator syntax, or mixed signed/unsigned arithmetic rules, or implicit int. Some of it, I believe, comes from having the language designed as its compiler was written, and design being tweaked so that it would be easier to implement - it's a hacker's pragmatic approach to making a tool that's needed for further progress (writing the OS) without wasting any more time than is necessary, but it doesn't result in a perfect thing - only something that's good enough.
66. Re:It'd be nice if ... by shutdown+-p+now · 2011-11-13 22:07 · Score: 1
 
 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.
 The design of generics in Java is flawed in more than one way, but can you give an example of "confusing code that can be extremely difficult to understand", especially "without a debugger" - that last part sounds completely nonsensical to me since Java generics are purely compile-time; they don't have any runtime variability by design (due to erasure).
 Anyway, there are many better examples of generics done right. My personal favorite are OCaml functors, which could be easily slapped on top of C with only minor syntactic differences, and provide an easy-to-understand yet extremely powerful tool for generic programming and metaprogramming, which would still be largely in the vein of C, with no magic stuff happening under the hood (you have to instantiate a functor and bind the result to a name before you use it, so instantiations are explicit).
67. Re:It'd be nice if ... by bertok · 2011-11-13 22:13 · Score: 1
 
 "char" is probably the most stable type in C
 But can't be used to represent characters, because Unicode requires at least 16 bits for the character type. So yeah... that's obvious.
 No problem, I'll use wchar_t, which has a nice dependable size of... 8, 16, or 32 bits, and may be either signed or unsigned.
 
 And btw in C you have intXX_t and uintXX_t types now.
 Are you sure? They're in only present in recent versions of the standard library... and wait for it... while they're defined to be exactly XX bits, they're not guaranteed to exist.
68. Re:It'd be nice if ... by shutdown+-p+now · 2011-11-13 22:15 · Score: 2
 
 http://thedailywtf.com/Articles/The-Integer-Cache.aspx
 It's a WTF. What, you never saw a C or C++ WTF?
 
 And it seems that you need a string builder class to help you manipulate strings. Sorry, but that tells me that you're doing strings wrong.
 It's one of the tradeoffs that you have when you design what your strings look like. In C++, they are mutable, but they are "value types" in Java terms - i.e. copying them around actually copies the buffer, so when you pass a string to a function, it can freely mutate it since it has the pointer. But copying like that ain't cheap - it's why you have to pass by const reference where possible. Often can't return by reference, though. RVO (and, in C++11, move semantics) help with that somewhat, but you're still almost certainly doing some unnecessary extra copies with those strings in any moderately complicated C++ progam.
 In Java, strings are reference types (or, in C++, you could treat it as a value type with a pointer to the buffer). Since there's no easy way to copy the buffer when passing by value (and requiring the caller to do so explicitly on every call would be very tedious), the only way to prevent the callee from mutating the referenced, potentially shared string is making it immutable. then you need a helper mutable class like StringBuilder to help you build those immutable strings in an efficient way, since otherwise you'll be allocating and throwing away a new immutable string on every iteration. On the other hand, strings tend to be just created once and passed around much more often than they are mutated, so this design has better perf for the most common case.
 Ruby (at least in 1.8) had a pretty insane design in that strings are reference types (same as everything else), but they're also mutable - so you have to be extra careful make a copy of the string in the function if you're planning on changing it, and copy the returned string value in case the caller tries to change it.
69. Re:It'd be nice if ... by shutdown+-p+now · 2011-11-13 22:17 · Score: 3, Insightful
 
 It's "broken" in a sense that, if you try real hard to break it, you can find ridiculous corner cases that can do that. In the meantime, there are millions of line of C and C++ code written using it, which compile and work just fine.
70. Re:It'd be nice if ... by PeterBrett · 2011-11-13 22:19 · Score: 2
 
 java.util.concurrent.atomic is a perfect example of why Java is not a viable choice for the work I'm doing. One of the tasks I currently have to handle is multiprocess disjoint set construction (using the wait-free union-find algorithm), on a very large corpus. This algorithm requires each disjoint set tree node to contain two fields: a reference to its superset, and a rank counter. In Java, the only choice I have is to use an array of AtomicStampedReference<V>, which will always occupy at least two platform words. Because I know the exact size of the corpus, in C I can easily do some trivial pointer arithmetic to halve the amount of storage required on 64-bit platforms. Not only does this allow me to process larger datasets on my workstation without suffering from memory exhaustion, but because the computation turns out to be memory bandwidth-limited, it allows me to process it faster as well.
 Oh, and .NET can DIAF.
 
 --
 Pirate Party UK
71. Re:It'd be nice if ... by Goaway · 2011-11-13 23:29 · Score: 1
 
 The demos I have done are all for specific hardware in embedded platforms, not x86 machines.
 And released at which party?
72. Re:It'd be nice if ... by BenoitRen · 2011-11-13 23:46 · Score: 3, Interesting
 
 Haven't you noticed how every cross-platform C/C++ library starts out with pages of pages of "MY_LIBRARY_INT32" and "MY_LIBRARY_EXPORT" and other redefinitions of "standard" types, keywords, and functions? That's because C is a badly designed language where the behaviour and/or availability of even basic language keywords like "int" is a crap shoot that depends on the compiler and the target processor type
 
 Well, duh. That's the entire point of C. You're complaining that it's a language close to the metal.
 Still, since C99 there are special integer types available that define exactly how large they are and if they're unsigned or not. Yes, they are widely available. It's been over 10 years since their introduction.
 
 Meanwhile, this Java code will work on all platforms, processors, and compilers, forever and ever:
 
 At least until Java decides to deprecate parts of its standard library. Java code written during the 90s no longer works. So much for "write once".
73. Re:It'd be nice if ... by Rob+Seace · 2011-11-14 00:11 · Score: 2
 
 But can't be used to represent characters, because Unicode requires at least 16 bits for the character type.
 Never heard of UTF-8 then, I take it? That works fine in regular old char arrays... (Though, to be fair, it introduces other issues, such as you can no longer depend on the length of the string being the number of characters in it...)
74. Re:It'd be nice if ... by AmiMoJo · 2011-11-14 00:55 · Score: 1
 
 Different tools for different purposes. I write microcontroller firmware mainly in C but drop to assembler when necessary. In the micro world the compiler's optimisations are both essential and occasionally problematic, but no-one has come up with anything better (which sort of implies that C is pretty good).
 Pick the best tool for the job. Some people try to force C++ onto microcontrollers with 1K RAM and no OS, just because being OO is somehow "better". These people are just as stupid as the ones who want to write desktop apps in assembler or who reject .NET out of hand because it isn't native code. .NET actually makes doing a lot of stuff, particularly GUI and OS integration, very quick and easy. There is nothing to stop you coding the critical parts in normal C either, which is what we are doing with a WinCE 7 app that combines a managed OpenGL accelerated GUI app in .NET, core processing in C and some really critical stuff in ARM NEON assembler.
 Of course we failed to use the best tool by not picking Android over WinCE 7, but someone swallowed the hype and it does do what we require of it.
 
 --
 const int one = 65536; (Silvermoon, Texture.cs)
 SJW, n: "Someone I don't like, and by the way I'm a fuckwit" - AC
75. Re:It'd be nice if ... by Anonymous Coward · 2011-11-14 01:07 · Score: 0
 
 When the bottom was reached, Perl was born.
76. Re:It'd be nice if ... by bertok · 2011-11-14 01:30 · Score: 1
 
 Oh, and .NET can DIAF.
 The Java version requires much more storage than you assume:
 - arrays of objects aren't packed, they're arrays of pointers, so 1 pointer per entry
 - the actual AtomicStampedReference objects will require 2 pointers for each of its fields (the 'value' and the 'stamp')
 - the 'stamp' values are boxed, so they're independently allocated on the heap, probably taking at least 1 more pointer-sized memory allocation somewhere.
 - but looking at the source code shows that it's even worse than that, because it stores its data indirectly inside a private class held by a AtomicReference field. That adds at least 2 more pointers.
 That's at least 6 words per entry.
 In contrast, C# has value types (structures), so it can pack the "value" reference and the "stamp" into either 2 pointers, or 1.5 if you mix 64-bit pointers and 32-bit ints. In C#, arrays of value types are packed, so the total size is... 1.5-2 pointers per entry, just like in C. Unlike C, you'd end up spending 10x less time on all the other fiddly stuff by using a high-level language with a massive standard library, so you'd have more time to work on your algorithm.
 That's just clearly wrong, so lets cleanse it with purifying fire.
77. Re:It'd be nice if ... by Anonymous Coward · 2011-11-14 01:44 · Score: 0
 
 How is the java language crapified? Are you speaking of the endless labyrinth of APIs? If so, why is that bad? You only have to use what you need. Are you speaking of generics and reformed looping syntax's? You don't have to use those either. Sit down, your ass is talking too much.
78. Re:It'd be nice if ... by Anonymous Coward · 2011-11-14 02:48 · Score: 0
 
 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.
 Seriously?
 GLib provides common data structures and regular expressions.
79. Re:It'd be nice if ... by PeterBrett · 2011-11-14 03:19 · Score: 1
 
 Thank you for confirming that Java sucks for anything that needs to be slightly performant.
 
 In contrast, C# has value types (structures), so it can pack the "value" reference and the "stamp" into either 2 pointers, or 1.5 if you mix 64-bit pointers and 32-bit ints. In C#, arrays of value types are packed, so the total size is... 1.5-2 pointers per entry, just like in C.
 I don't know of any architectures that can do unaligned compare-and-swap of a element with a non-power of two extent, so you need to use either a 64-bit (CMPXCHG8B) or 128-bit (CMPXCHG16B) combined value.
 My issue with .NET is its lack of portability and extremely dubious legal status. I have no opinion on the language's technical aspects.
 
 --
 Pirate Party UK
80. Re:It'd be nice if ... by Anonymous Coward · 2011-11-14 03:28 · Score: 0
 
 Though, to be fair, it introduces other issues, such as you can no longer depend on the length of the string being the number of characters in it...
 That only matters if you know nothing about Unicode and think you can count "unicoder characters" using 32-bit integer arrays or, even better, using UCS-2(calling it UTF-16, of course).
 A 32-bit integer can hold a full code point, which may or may not be a glyph, or part of a glyph, which then may or may not be a letter according to locale-specific collation rules.
 Face it people. The people developing stuff like C, UNIX and UTF-8 can run circles around you, even after death.
81. Re:It'd be nice if ... by Toonol · 2011-11-14 03:40 · Score: 1
 
 Java's terrible, but I don't want to get into that here.
 
 C is nearly a great, elegant language. It's core is terrific; a simple syntax that lets you have nearly the efficiency and versatility of assembly, while providing enough abstraction to allow you to address problems in as high a level as you could desire.
 
 There's a few clunky parts; like you mention, it would have been better if you could, for instance, rely on a short int being 16 bits while an int was 32. The worst part, though, is the header structure and preprocessor. If not for the crazy and confusing web of declarations, definitions, and conditional includes, C could have been the language for everyman.
 
 I wish for a traditional, declarative, compiled language, as close to the metal as C, but which had sensible package management and had one more pass to clean up all the weird little quirks... and a more modern standardized API.
82. Re:It'd be nice if ... by bored · 2011-11-14 03:47 · Score: 1
 
 Many common programming tasks require extensive pointer manipulation in C.
 Pointer arithmetic, or pointer storage (aka linked lists?), or argument passing?
 Frankly, I suspect you have been reading your old copy of K&R to much. Most modern (aka written in the last 20 years, by experienced developers) C rarely does pointer arithmetic. There isn't any reason, as the compilers/CPUs started being able to optimize the array syntax (var[offset]) to perform equivalently (if not faster) than similar pointer based code. When that happened the readability/debuggability/security aspects outweighed the slight performance difference of doing it the way K&R demonstrated in the 70's. The problem is that to many newbies listen to the old guys, talking about how great the K&R book is for learning C, and proceed to mimic many of the harmful tricks and styles in that book.
83. Re:It'd be nice if ... by zevans · 2011-11-14 03:58 · Score: 1
 
 If you implement something well, you won't need to go back to it once every six months.Once you've done that to the five or six key systems, you run out of stuff to fix, and that's the end of that job in that organisation.
 
 --
 "... and more and more now there are all kinds of electronic goodies available" -- Pink Floyd 1972
84. Re:It'd be nice if ... by makomk · 2011-11-14 04:05 · Score: 1
 
 Pretty much all modern C compilers support stdint.h for integers of specific widths. Of course, once you get into exotic embedded hardware, you may not have native support for 32-bit integers, or 16-bit ones, or even 8-bit ones! (Also, have fun doing anything that requires unsigned integers in Java, because the language designers didn't think you needed them.)
85. Re:It'd be nice if ... by Anonymous Coward · 2011-11-14 05:09 · Score: 0
 
 Headers in 2011? Really?
 Fixed that for you.
86. Re:It'd be nice if ... by phantomfive · 2011-11-14 05:18 · Score: 1
 
 "The design of generics in Java is flawed in more than one way, but can you give an example of "confusing code that can be extremely difficult to understand", especially "without a debugger" - that last part sounds completely nonsensical to me since Java generics are purely compile-time; they don't have any runtime variability by design (due to erasure)."
 
 Sure. This is a serious problem with codebase I'm currently working on, even the author can't always figure out what is happening without using a debugger. We have declarations like <a href="http://grepmonster.wordpress.com/2009/09/05/complicated-java-method/">this one</a> all over the place in the code. 
 The thing that makes it bad is when you are looking at code, and a method gets called on a generic, it's hard to know where the code will go next unless you know which concrete class will be there at runtime. But to know that, you have to find out where the class was created, and to do that you have to follow the path through the code in reverse, which is harder than following the path forward. Note this isn't just a problem with generics, code that is subclassed a lot can be just as confusing (in my tiredness last night, I actually said 'generics' when I meant subclassing, lol, but I guess it turned out alright since generics can have the same problem). Technically you COULD figure it out just by reading the code without the debugger, but it can take a lot of time. 
 Our particular codebase is also complicated by the fact that it has a lot of threads, and the author failed to consider the entire lifecycle of the thread at design time (when it is safe for a thread to be born, when it is safe for it to die), and things which SHOULD by synchronous end up being hard to figure out what order they will happen in as well. 
 Also, I would like to mention, in my way of grading code, the #1) most important thing is, "does it work?" but the #2) most important thing is, is it readable? (That is, can I figure out the structure?)
 
 --
 "First they came for the slanderers and i said nothing."
87. Re:It'd be nice if ... by phantomfive · 2011-11-14 05:26 · Score: 1
 
 Yeap. File that under "yet another crappy basic library implementation that I had to learn for exactly one project and never again." When do you get to link your C code against the Gnome library, especially when you are doing embedded?
 
 --
 "First they came for the slanderers and i said nothing."
88. Re:It'd be nice if ... by lgw · 2011-11-14 07:26 · Score: 1
 
 Meanwhile, C and C++ have poor support for multi-threading, especially if code needs to be portable.
 The new C++ has
 
 void doStuff(); std::thread t(doStuff);
 
 So there you go.
 
 --
 Socialism: a lie told by totalitarians and believed by fools.
89. Re:It'd be nice if ... by Anonymous Coward · 2011-11-14 10:11 · Score: 0
 
 A good programmer can (and does) write well structured, clean, DOCUMENTED and maintainable product in any language.
 Give a single example of a well structured, clean, documented, and maintainable product written in any of the .NET variants.
 While it's true that it could, in theory, be done, it's also true that it never has.
90. Re:It'd be nice if ... by Anonymous Coward · 2011-11-14 10:24 · Score: 0
 
 The only thing you really need the preprocessor for is to guard against multiple inclusion for your exported API headers.
 It is not required per se, it is just about playing nice, to yourself and to other people using your code, and is the skeleton of an API .h file in a C programmers' workflow.
 So here's this oh so difficult .h skeleton of a my_nice_api.h header containing preprocessor use:
 #ifndef MY_NICE_API_H #define MY_NICE_API_H
 /* put your stuff in here. */
 #endif /* MY_NICE_API_H */
 you can copy+paste it from here for all your api headers, since it seems so difficult in your opinion to come up with this on your own.
91. Re:It'd be nice if ... by Anonymous Coward · 2011-11-14 10:38 · Score: 0
 
 ..and to actually #include, of course..
92. Re:It'd be nice if ... by fatphil · 2011-11-14 11:22 · Score: 1
 
 > > http://thedailywtf.com/Articles/The-Integer-Cache.aspx
 > It's a WTF. What, you never saw a C or C++ WTF?
 
 I've seen C code WTFs, yes. However, read that article again - this particular WTF is a workaround for a *WTF in the language itself*. One I believe they kludged later (when the non-koolaid-drinkers had become aware of it), but if it takes you major 6 generations of a language before you're starting to be clear of WTFs (and I don't even know if that's true at all), then perhaps you were beating a dead horse to begin with.
 
 --
 Also FatPhil on SoylentNews, id 863
93. Re:It'd be nice if ... by GuB-42 · 2011-11-14 11:31 · Score: 1
 
 Meanwhile, this Java code will work on all platforms, processors, and compilers, forever and ever:
 public class Compressor { public byte[] compress( byte[] data ) { ... } public byte[] decompress( byte[] data ) { ... } }
 A tad "cleaner" than 50KB of macros, don't you think?
 "char *compressor_compress(char *data)" in C will work on all platform, processors and compilers too. Also the portability of Java is a myth. It just shifts the problem from the physical machine to the virtual machine. Not all JVMs are compatible and I actually had more portability problem with Java than with C.
94. Re:It'd be nice if ... by shutdown+-p+now · 2011-11-14 11:36 · Score: 1
 
 this particular WTF is a workaround for a *WTF in the language itself*
 I'll just cite it:
 "... a harebrained effort to save memory by not creating a new Integer."
 Saving memory by caching Integer instances is a pretty dumb thing to do. For the most part, they're short-lived objects, and GC (which is very good specifically at dealing with such things) will quickly collect any that accumulate. Even those that do accumulate (in collections etc), are not going to matter in any Java program of a decent size, because the language is generally quite wasteful of memory elsewhere as well. About the only case where I think it might matter is in a J2ME app, but writing in J2ME is a masochistic exercise roughly equivalent to gouging your both eyes out with a spoon, so I'm not particularly concerned about that corner case.
 Integers are cached since Java 5 if you use Integer.valueOf rather than constructor (or implicit boxing, which uses valueOf) for values between -128 and 127. However, this is mainly there to be able to use the faster reference equality comparison, and avoid an extra dereference to compare values.
 Anyway... I do agree with you that Java is chock full of design flaws. For example, most instances of integer boxing would be completely unnecessary if it had proper generics that accepted primitive types as is (as e.g. C# does), and then it wouldn't really make sense to pay much attention to boxing performance & memory use at all. There are many others, of course. What I was saying, is that your particular examples of why Java is badly designed are not good examples, especially not when there's much more meaty stuff there.
95. Re:It'd be nice if ... by Khyber · 2011-11-14 15:53 · Score: 1
 
 The ones where I make millions of dollars for further research because it's a working system and they have all the code to maintain it if they so choose, we pop champagne and fire up cigars.
 
 --
 Still waiting on Serviscope_minor to wake up to fucking reality and realize that Jessica Price isn't going to fuck him.
96. Re:It'd be nice if ... by antifoidulus · 2011-11-14 19:55 · Score: 1
 
 Um, this should not be REQUIRED at all, that was my entire point. Yes I can do it on my own, but why should I have to? Why can't C just include an import statement that does this for me? Also, there are 0 rules on naming conventions, it's possible that a naming collision can cause really hard to track down errors.
 
 --
 Monstar L
97. Re:It'd be nice if ... by Goaway · 2011-11-15 02:38 · Score: 1
 
 Look, you were talking about the demoscene. Pretty much all demoscene releases happen at demo compos at demo parties. That is pretty much the whole point.
 If you weren't taking part in a compo, you have nothing whatsoever to do with the demo scene.
98. Re:It'd be nice if ... by Khyber · 2011-11-15 14:14 · Score: 1
 
 So funny you choose to exclude other demo projects from the demoscene because we don't employ techno soundtracks and FPS shit-perspectives instead of doing something USEFUL with ultra-limited resources in real-time.
 Oh well, just shows the narrow-mindedness of individuals.
 
 --
 Still waiting on Serviscope_minor to wake up to fucking reality and realize that Jessica Price isn't going to fuck him.
99. Re:It'd be nice if ... by Goaway · 2011-11-15 15:00 · Score: 1
 
 I am not "choosing to exclude" anything, those just aren't part of the demoscene. "The demoscene" is not a vague, nebulous concept you can apply as you see fit, it is just the name for a specific subculture centered around demo parties.
 You were telling people to look up the demoscene, but it seems it's you who should be doing it. You seem gravely misinformed about what it actually is.
Underhanded C contest should return by vadim_t · 2011-11-13 06:36 · Score: 5, Interesting

The IOCCC is cool, but the Underhanded C Contest was a lot more valuable.
The entries for the IOCCC can show a lot of cleverness, but nobody in their right mind would accept such code. The beauty of the Underhanded C ones is that the code looks reasonable, but does extremely undesirable things.
1. Re:Underhanded C contest should return by Truekaiser · 2011-11-13 06:57 · Score: 3, Interesting
  
  call me paranoid but this contest and the ioccc are the reasons why i don't particularly let anything from s.e.l. touch my systems. i am not a good enough coder to be able to tell if what it's doing is what it says it's doing or something the cia wants it to do..
2. Re:Underhanded C contest should return by Anonymous Coward · 2011-11-13 07:15 · Score: 0
  
  Except that they didn't hold a contest in two years and didn't even announce any winners of the last one held.
3. Re:Underhanded C contest should return by martin-boundary · 2011-11-13 09:31 · Score: 5, Insightful
  
  Then you should read Ken Thompson on putting backdoors in C compilers. Do you trust your build system?
4. Re:Underhanded C contest should return by Anonymous Coward · 2011-11-13 10:46 · Score: 0
  
  s.e.l.? What the fuck does that mean?
  Schweitzer Engineering Laboratories?
  Solar Energy Laboratory?
  Even searching for it shows nothing in particular. Search Engine Land, maybe?
5. Re:Underhanded C contest should return by martin-boundary · 2011-11-13 13:55 · Score: 2
  
  s.e.l.
6. Re:Underhanded C contest should return by Anonymous Coward · 2011-11-13 15:06 · Score: 0
  
  Yes, because I'm sure the CIA is extremely interested in what you're doing. They have agents working in shifts!
This makes me so happy... by Anonymous Coward · 2011-11-13 06:36 · Score: 2, Insightful

I hope there are many submissions... It's things like this that teach you the FULL amount of abuse a language can take while still making something that works. :-D
I would like to see this rule illustrated by bogaboga · 2011-11-13 06:36 · Score: 2

To illustrate some of the subtleties of the C language.
The C language is not my thing per se, but I'd like to see simple C program code the illustrates the subtleties of C. Anyone?
1. Re:I would like to see this rule illustrated by Anonymous Coward · 2011-11-13 06:49 · Score: 4, Insightful
  
  Look up "Duff's Device". There's a good example.
2. Re:I would like to see this rule illustrated by Bomazi · 2011-11-13 07:47 · Score: 2
  
  This link:http://www.eecs.berkeley.edu/~necula/cil/cil016.html
  describes some corner cases of C. You need to have some prior to knowledge of C to appreciate the non-obviousness of the examples though.
3. Re:I would like to see this rule illustrated by fatphil · 2011-11-13 21:10 · Score: 1
  
  If you know anything about C, you'll see that whoever wrote that page has serious problems in his knowledge of C. (At least from looking at the first 2 examples. I really didn't look any further, it was 2-strikes-and-you're-out, to be honest.)
  
  --
  Also FatPhil on SoylentNews, id 863
4. Re:I would like to see this rule illustrated by Anonymous Coward · 2011-11-13 21:13 · Score: 0
  
  Some of the examples are non-obvious to the compiler to the point that 16.2 example 4 ("A cute little example") doesn't compile, and 16.3 example 1 invokes undefined behavior (right shift of a negative quantity) so the compiler is allowed to do anything.
  captcha: sinister
entry by Anonymous Coward · 2011-11-13 06:58 · Score: 0

#include "stdio.h"
int main() { char buffer[80]; printf( "hello, world.\n" ); repeat: gets( buffer ); printf( "you know, I miss all you guys.\n" ); gets( buffer ); printf( "I was a pretty good guy, don't you think? But he doesn't seem to think so.\n" ); goto repeat; return 0; }
Use Duff's Device by Anonymous Coward · 2011-11-13 06:59 · Score: 1

Use Duff's Device! (Responsibly)
Use Duff's Device! (Responsibly)
1. Re:Use Duff's Device by JonySuede · 2011-11-13 07:27 · Score: 5, Interesting
 
 don't use them anymore, go read that post: http://lkml.indiana.edu/hypermail/linux/kernel/0008.2/0171.html
 
 --
 Jehovah be praised, Oracle was not selected
2. Re:Use Duff's Device by Anonymous Coward · 2011-11-13 08:06 · Score: 5, Interesting
 
 Jim Gettys has a wonderful explanation of this effect in the X server. It turns out that with branch predictions and the relative speed of CPU vs. memory changing over the past decade, loop unrolling is pretty much pointless. In fact, by eliminating all instances of Duff's Device from the XFree86 4.0 server, the server shrunk in size by _half_ _a_ _megabyte_ (!!!), and was faster to boot, because the elimination of all that excess code meant that the X server wasn't thrashing the cache lines as much.
 
 Emphasis mine. That's REALLY freaking interesting. Posting this AC before modding you up.
3. Re:Use Duff's Device by TheRaven64 · 2011-11-13 09:30 · Score: 4, Insightful
 
 It's the main reason why C++ does well in microbenchmarks and does so much worse in real-world usage. It encourages a lot of inlining, which reduces branching but increases instruction cache usage. It's difficult to benchmark well, because instruction cache pressure changes over time depending on what else is happening with the system.
 
 --
 I am TheRaven on Soylent News
4. Re:Use Duff's Device by smellotron · 2011-11-13 14:14 · Score: 1
 
 [C++] encourages a lot of inlining, which reduces branching but increases instruction cache usage.
 
 C++ also encourages object-oriented programming techniques, which spreads functional responsibility across multiple classes. This naturally leads to more, smaller functions that may also mess with the instruction cache.
5. Re:Use Duff's Device by Anonymous Coward · 2011-11-13 16:04 · Score: 1
 
 Your link is very interesting and I'm glad you posted it, but; parent's* comment was a (semi-obscure?) reference to The Simpsons.
 *different AC, in case you wondered.
6. Re:Use Duff's Device by shutdown+-p+now · 2011-11-13 22:19 · Score: 1
 
 But then all those small functions inline, and you end up with the same big chunks of code as in C.
7. Re:Use Duff's Device by shutdown+-p+now · 2011-11-13 22:20 · Score: 1
 
 I haven't ever used a C++ compiler which didn't have some way to control inlining. Some even let you set hard limits on levels on resulting function size.
 And it's not like C can't be inlined just as well. Especially if you enable link-time code generation, where compiler can peek across translation unit lines.
8. Re:Use Duff's Device by TheRaven64 · 2011-11-13 22:49 · Score: 1
 
 I haven't ever used a C++ compiler which didn't have some way to control inlining
 Yes, I know, I do work on a couple of C++ compilers...
 
 Some even let you set hard limits on levels on resulting function size
 ... but it's always done at that kind of granularity. That's the problem. In every case, inlining can appear to be a locally correct optimisation. Every function that has something small inlined into it will become faster. You can measure that with microbenchmarks. The problem is that doing this
 
 And it's not like C can't be inlined just as well
 Not as easily. The C specification doesn't define ODR linkage, which makes creating inline functions more difficult. C++ templates get expanded in every compilation unit and either inlined or emitted with link-once ODR linkage. This means that the compiler is far more likely, given C and C++ code, to have something that is used in a lot of translation units available to inline.
 
 Especially if you enable link-time code generation, where compiler can peek across translation unit lines.
 But if you're doing LTO then the compiler will also be considering the total binary size with respect to the CPU cache. More importantly, the inlining decision in modern compilers also factors in the number of call sites. If something has a single call site and is not exported outside of the compilation unit, it will always be inlined because there is never a case when that is the wrong thing to do. When the compiler can see more call sites, it is less likely to do make the decision to inline.
 Unfortunately, the inlining pass tends to happen twice, once per compilation unit and once with LTO, and there is no uninline pass in any compiler I've used (it's actually one of the things on my todo list).
 
 --
 I am TheRaven on Soylent News
9. Re:Use Duff's Device by TheRaven64 · 2011-11-13 23:10 · Score: 1
 
 Not really. Small functions that are called a lot are fine for icache usage. They're often better than big functions with some hot and some cold code paths. One of the optimisations that I'm currently working on is to move cold code paths out of big functions into a separate function so that they can reduce icache pressure.
 
 --
 I am TheRaven on Soylent News
10. Re:Use Duff's Device by smellotron · 2011-11-14 01:55 · Score: 1
 
 They don't inline by default, unless you always code the implementations inline in the class declaration. Plus, the extra register pressure from multiple thiss doesn't go away when you inline (admittedly, this doesn't matter as much on x86_64).
11. Re:Use Duff's Device by smellotron · 2011-11-14 02:14 · Score: 1
 
 hot/cold separation is very important, true. however, hot/cold doesn't tend to get factored into the object model by designers, because refactoring is touted as an activity that doesn't change the program's behavior. In my experience with a variety of C++ developers, getting the benefits you speak of "for free" doesn't happen.
12. Re:Use Duff's Device by TheRaven64 · 2011-11-14 03:53 · Score: 1
 
 Sorry, I was referring to your comment about OOP, not specifically C++. C++ only vaguely support OOP. If you're using an actual object-oriented language, then you get very different code (for one thing, the object code tends to be one or two orders of magnitude smaller).
 
 --
 I am TheRaven on Soylent News
13. Re:Use Duff's Device by Toonol · 2011-11-14 03:58 · Score: 2
 
 I wonder if FORTH would be particularly efficient on today's processors, for that reason? It is incredibly compact, with generally tiny functions nestled deeply. An entire FORTH system could sit in a modern cache.
14. Re:Use Duff's Device by TheRaven64 · 2011-11-14 05:18 · Score: 1
 
 Yes. Take a look at some of the OpenFirmware implementations. Even a pretty rubbish FORTH compiler tends to achieve reasonable speed.
 
 --
 I am TheRaven on Soylent News
15. Re:Use Duff's Device by shutdown+-p+now · 2011-11-14 10:32 · Score: 1
 
 They don't inline by default, unless you always code the implementations inline in the class declaration.
 That's not true. The presence of "inline" declarator, even implicit one from writing the bodies inside the class, generally doesn't affect the compiler these days. If it knows what the function body looks like at the point it is called, it will try to inline it if other criteria match, regardless of "inline". Even across translation unit, there's link-time optimization, where the compiler "sees" all translation units at once and does inlining across their boundaries.
 
 Plus, the extra register pressure from multiple thiss doesn't go away when you inline
 
 This is assuming that a given function even needs "this". If the receiver is stack-allocated in the caller function - a parameter or local, or field of the same (a very common case) - inlined code will just access fields directly on the stack.
 Basically, to defeat inlining and starve registers with "this", you need to do a lot of virtual calls. But that's not modern idiomatic C++, where compile-time polymorphism via templates is preferred over runtime vtable polymorphism, precisely because it gives optimizer, and specifically inliner, more to work with.
16. Re:Use Duff's Device by smellotron · 2011-11-14 17:36 · Score: 1
 
 They don't inline by default, unless you always code the implementations inline in the class declaration.
 
 That's not true.
 
 I did not mean to imply that inline guarantees that the function will be inlined. Sorry for the confusion, perhaps that was poorly worded. I meant the converse (not inverse): that omitting inline may prevent the compiler from performing an inlining optimization. If the function is out-of-line, then link-time optimization is required for inlining. If the function is out-of-line and linked into a shared library, then inlining outside of the shared library is impossible.
 
 The presence of "inline" declarator, even implicit one from writing the bodies inside the class, generally doesn't affect the compiler these days.
 
 Maybe not generally, but let me provide examples where it matters. 1) If you use GCC's -fvisibilty-inlines-hidden when compiling PIC, the compiler will bypass the PLT and therefore may inline code that it would otherwise assume may be redirected (e.g. by LD_PRELOAD). 2) If you define a member function as inline within an implementation, GCC will bypass the PLT in the same way, and it may or may not actually inline the code.
 
 This is assuming that a given function even needs "this".
 
 Aside from functors used in template functions, every member function should be using this or it should not be a member function. I think we both agree that the type of functors in "modern idiomatic C++" to which you refer should inline well. But I don't think these functions are representative of C++ OO code on the whole.
 
 Basically, to defeat inlining and starve registers with "this", you need to do a lot of virtual calls.
 
 Or build shared libraries, or lack access to a toolchain that performs link-time optimization, or use a toolchain that sucks at inlining non-leaf functions.
17. Re:Use Duff's Device by shutdown+-p+now · 2011-11-14 19:35 · Score: 1
 
 I did not mean to imply that inline guarantees that the function will be inlined. Sorry for the confusion, perhaps that was poorly worded. I meant the converse (not inverse): that omitting inline may prevent the compiler from performing an inlining optimization. If the function is out-of-line, then link-time optimization is required for inlining.
 That is what I was talking about, as well. Omitting the "inline" specifier, by itself, does not prevent compiler from inlining the function - so long as it can see its body, it can still inline, and most will indeed do so regardless of whether it's actually marked "inline". Now normally this only applies to calls between (non-virtual) methods of the same class, since stuff in headers has to be inline if you want them to be includable more than once. But that's just a language rule, and not directly related to actual inlineability.
 
 If the function is out-of-line and linked into a shared library, then inlining outside of the shared library is impossible.
 Well yes, obviously, you can't inline across shared library boundaries. That's actually one area where JIT-compiling VMs can beat C/C++ in practice - since they can inline across runtime boundaries (the other area is the ability to instantiate generics across shared library boundaries, as e.g. VM can do).
 
 Aside from functors used in template functions, every member function should be using this or it should not be a member function.
 
 What I meant is the member function that doesn't actually need address of the object it belongs to for anything other than accessing member fields. When that is true, more often than not, the function can be inlined in such a way as to access those fields directly from memory locations assigned to them by the caller. In fact, for lightweight objects, it is entirely possible that the object does not even exist as a single memory blob anywhere in compiled code - e.g. if you allocate an std::pair<int,int>, and pass it around to functions by value, it would be pretty common for the entire call chain to be inlined, and the pair's first and second fields being mapped directly to registers. Since there's no memory location, there's no "this" proper in that case. And it's actually quite common - e.g. many STL containers have simple immediate representations (e.g vector - size + capacity + pointer to buffer), and don't contribute "this" to register starvation.
 
 Or build shared libraries, or lack access to a toolchain that performs link-time optimization, or use a toolchain that sucks at inlining non-leaf functions.
 Are there any mainstream C/C++ toolchains that don't support LTO/LTCG? VC++ had it for, I think, three major releases now. g++ has also had it for some time. Not sure about Intel, but I'd be surprised if they don't have it.
 And I've been pretty impressed at how aggressive C++ compilers can actually inline things. I once wrote a template that expanded in a series of 2^16 nested function calls, which, when unrolled, would give an if-else over a table 2^16 integers (don't ask why). VC++2008 actually inlined the whole thing entirely, and then scraped all the empty branches - granted, it took it about 5 minutes to actually do that, but still...
Awesome! by Anonymous Coward · 2011-11-13 07:13 · Score: 4, Funny

It's about time I got some more reference code.
1. Re:Awesome! by achowe · 2011-11-14 02:58 · Score: 2
  
  http://www.ioccc.org/winners.html#H Look at Anthony C Howe (me). 1991 (vi clone in 1526 bytes source, went on to become the floppy disk rescue editor "ae" in early Debian) and 1993 (egrep) are particularly interesting for their data structures. My favourite from someone else is http://www.ioccc.org/ /years.html#1992_buzzard.2 (forth clone); took me ages to understand this this gem way back then. And for those who think I'm bragging, shit ya, since the IOCCC has no real prize, they say bragging rights is all the winners get.
  C is not about being cryptic, though it certainly can be when done badly. Its about clever data structures, being methodical, disciplined, where small is beautiful; instead of memory and CPU cycles being cheap.
  Another great C example is the early "Empire" http://www.classicempire.com/ before there was fancy graphics and Sid Meyer's Civilisation.
What happened to the IUPCC? by Anonymous Coward · 2011-11-13 08:03 · Score: 1

What happened to the International Unobfuscated Perl Code Contest (IUPCC)? ... Oh wait it's impossible to write unobfuscated perl :)
The Internet is based on C by Required+Snark · 2011-11-13 08:12 · Score: 5, Insightful

I find all the "C sucks" comments to be both amusing and stupid. Without C code there would literally be no Internet. Every bit you are sending and receiving uses C. The two operating systems that represent 99.99% or more of the running computers that are online run C. Both Windows and Linux use the BSD TCP/IP stack.
If C did not get the job done for this kind of computing then it would have been replaced. The fact that C thrives in the systems programming domain is a tribute to it's utility.
A proficient C coder can write clear, maintainable, efficient code that runs on many platforms. This requires both skill and practice. Not everyone is capable of doing this. It requires the ability to keep multiple competing abstractions in mind when coding. I think a lot of people try this and find it difficult and then blame the language. Those who persevere and learn this style of working can usually move on to other kinds of programming and also do excellent work.
Some problem domains require different languages and different skill sets. Personally, I like writing code where I know that if I were to look at the assembly code generated by the compiler I can see how it relates to the C code I wrote. I rarely do this, but it's good to know that I can if I want to. I'm doing any C coding now, because I always use the appropriate language to the task. But I also know that my C coding skills give me a distinct advantage in solving difficult problems, no matter what they are,

--
Why is Snark Required?
1. Re:The Internet is based on C by Sduic · 2011-11-13 09:26 · Score: 5, Interesting
  
  Without C code there would literally be no Internet.
  Because obviously only C is Turing-complete.
  Before I stir up any vitriol, I'm just kidding. I think C is under appreciated precisely because is provides only a thin abstraction that (hopefully) maps well to the target architecture, but otherwise stays out of the way. That is to say, when all you have is a hammer, you can easily shoot yourself in the foot.
  
  --
  *this space intentionally left blank
  "One of the four pointers saying 'come and see', and I saw, and beheld a white
2. Re:The Internet is based on C by Anonymous Coward · 2011-11-13 09:32 · Score: 1
  
  Both Windows and Linux use the BSD TCP/IP stack.
  Nope. Wrong on both counts.
  Linux always had its own stack (rewritten several times), Windows used some user-space utilities from BSD, no stack.
3. Re:The Internet is based on C by Anonymous Coward · 2011-11-13 09:49 · Score: 0
  
  Well, there are a couple things that suck about C, mostly syntactical and not a big deal. Disclaimer, I'm very ignorant of C because I've never written a large program in it (studied C for awhile after 6502 and gave up) :
  - Choosing == for equality operator and = for assignment. I liked how Pascal uses := for assignment. Ugly, but stands out, even after 20 hour coding marathons (not that I've done 20 hour coding marathons... )
  - The keyword "char" should be replaced with "byte."
  - I hate "long long" - should be "wide", i.e. "wide int," or better yet, you should be able to explicitly state the width of data types with "int" being the natural "bitness" of the CPU (and sizeof(int) returning that).
  - "bool" doesn't work right.
  - 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.
4. Re:The Internet is based on C by dlgeek · 2011-11-13 09:55 · Score: 3, Informative
  
  #include
  uint16_t x = 0; /*unsigned 16 bit integer */
  int32_t y = 0; /*signed 32 bit integer */
  
  Almost every platform I've ever worked on has stdint...
5. Re:The Internet is based on C by Anonymous Coward · 2011-11-13 09:58 · Score: 1
  
  The fact that C thrives in the systems programming domain is a tribute to it's[sic] utility.
  
  It's more of a tribute to C being a fancy assembler with a function calling convention. Yes, it's suitable for writing operating system kernels and not much else.
  
  A proficient C coder can write clear, maintainable, efficient code that runs on many platforms. ... Not everyone is capable of doing this. It requires the ability to keep multiple competing abstractions in mind when coding.
  Keyword: cognitive load. Case in point: hilariously excrutiating code example in linux man page of snprintf. If you need to jump through all these burning hoops to do something this mundane, imagine how much more your proficient C coder could achieve in a more sensible laguage with the same amount of effort.
  Of course nobody bothers with the burning hoops so that's why we have buffer overflows.
  
  I like writing code where I know that if I were to look at the assembly code generated by the compiler I can see how it relates to the C code I wrote.
  You (or probably someone else) can do that just as well with C++, java bytecode and others.
6. Re:The Internet is based on C by Billly+Gates · 2011-11-13 10:03 · Score: 1, Interesting
  
  No language is perfect and I like to think of using a particular language for a particular purpose. Some places C should not be used today. Gnome is a classic example if you want to bind OO languages with GObject.
  One issue with C (I know I am going to get flamed here) is security. Most of Windows security flaws are from C due to buffer and stack overlfows, and even vector attacks that languages like Pascal handle better when turned into assembly code. The Marines used old macs for years for this reason. I am not a computer science major so you can flame all you want on me not knowing anything, but XP SP2 and OpenBSD had to introduce special libraries due to the fact that a buffer and stack overflow can result in code execution. Unix had a bad wrap with security too early on before Windows 2000 and much of that could be due to C and its libraries. Don't give me it is a the programmers fault as he or she has no clue what the resulting assembly code does and how it handles when something is full.
  I am not a troll here or anti C but it is something overlooked by programmers who only grew up with C, C++ or Java/C# which are all derived or influenced by C itself.
  
  --
  http://saveie6.com/
7. Re:The Internet is based on C by mdf356 · 2011-11-13 10:48 · Score: 3, Insightful
  
  stdint.h came in with C99. There were decades where people hand-rolled their own versions so network communications would work...
  
  --
  Terrorist, bomb, al Qaeda, nuclear, yellowcake, kill, assassinate. Carnivore is dead... long live Echelon.
8. Re:The Internet is based on C by mdf356 · 2011-11-13 10:52 · 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.
  
  --
  Terrorist, bomb, al Qaeda, nuclear, yellowcake, kill, assassinate. Carnivore is dead... long live Echelon.
9. Re:The Internet is based on C by Carl+Drougge · 2011-11-13 11:10 · Score: 2
  
  Keyword: cognitive load. Case in point: hilariously excrutiating code example in linux man page of snprintf. If you need to jump through all these burning hoops to do something this mundane, imagine how much more your proficient C coder could achieve in a more sensible laguage with the same amount of effort.
  A sensible C coder might use vasprintf instead of the example in that manpage. The fact that all the standard library functions aren't great for all (or sometimes any) use cases is hardly unique to C.
10. Re:The Internet is based on C by Anonymous Coward · 2011-11-13 11:12 · Score: 0
  
  hm all that hyper shit was totally based on systems built around pascal, here is the point though since your some type of evangelist on C... just becuase we NOW use rubber on our wheels does NOT mean we would not have wheels without rubber
  now kindly take your fucked up short hand bullshit exploit ridden shitty ass language and go fuck yourself
  thanks ... the world who do not think that ATT and microsoft are the only ways to do it.
11. Re:The Internet is based on C by cratermoon · 2011-11-13 12:22 · Score: 1
  
  htons() and ntohs() and related functions are still important, too.
12. Re:The Internet is based on C by Old+Wolf · 2011-11-13 12:27 · Score: 1
  
  A sensible C coder might use vasprintf instead of the example in that manpage. The fact that all the standard library functions aren't great for all (or sometimes any) use cases is hardly unique to C.
  The *a*printf functions are not in the C standard, so the portable coder would not use them. I guess opinion may vary about what is 'sensible' :)
13. Re:The Internet is based on C by Anonymous Coward · 2011-11-13 13:00 · Score: 0
  
  A proficient C coder can write clear, maintainable, efficient code that runs on many platforms.
  The problem isn't the great C coders who can write awesome code. It's the mediocre ones that turn it into a horrifying train wreck. C and C++ give you all the tools, including all the tools to get yourself into trouble.
14. Re:The Internet is based on C by martin-boundary · 2011-11-13 14:01 · Score: 0
  
  You realize (I assume) that those are *lower* bounds on the storage size. There's no guarantee that uint16_t is in fact (only) 16 bits long...
15. Re:The Internet is based on C by Anonymous Coward · 2011-11-13 14:02 · Score: 0
  
  A proficient C coder can write clear, maintainable, efficient code that runs on many platforms.
  The problem isn't the great C coders who can write awesome code. It's the mediocre ones that turn it into a horrifying train wreck. C and C++ give you all the tools, including all the tools to get yourself into trouble.
  And you somehow think mediocre programmers can write more maintainable code in Java, Perl, Javascript, Python, Groovy, Scala, C# etc... ? The higher abstraction levels of these languages in no way guarantees that you won't get unmaintanaible code. If you think otherwise you need a reality check.
16. Re:The Internet is based on C by martin-boundary · 2011-11-13 14:22 · Score: 3, Insightful
  
  Nonsense. Windows security flaws have historically been due to boneheaded design decisions. Windows was never meant to run as a node on the internet, that functionality was retrofitted when Bill decided to do his famous 180 about turn on the computer highway because he'd missed the internet on-ramp. "Security" was retrofitted ten years later.
  Problems with the C standard library certainly do exist and can expose security issues, but Windows security problems exist because the OS design emphasises user friendliness and backwards compatibility over tight protections.
  It's like inside your home, you don't lock all your cupboards, drawers and doors - that would be painful, eg to walk from the kitchen to the living room you'd take out your key, unlock the door, open go through shut, relock the door, each time. To make your home livable you keep it insecure, and that's how Windows was designed from the ground up.
  But now suppose there's a magic internet wormhole that opens in your toilet room, and anybody can enter your house. Suddenly it makes sense to have locks on all the doors and cupboards etc, but it's too late. Windows + Internet = insecure.
  Unix doesn't have this problem, because Unix was always designed as a hotel (multiuser OS) rather than a home. So there's locks on the rooms and the swimming pool needs an access card etc. If a wormhole opens in the hotel lobby or even in one of the guest rooms, there's limited access to most areas by design.
17. Re:The Internet is based on C by Brian+Feldman · 2011-11-13 16:08 · Score: 1
  
  So what non-Linux, non-FreeBSD Unix do you regularly use and target software for?
  
  --
  Brian Fundakowski Feldman
18. Re:The Internet is based on C by DMFNR · 2011-11-13 16:57 · Score: 1
  
  When I write C, I put my splats next to the variable name too, it's just how I've always done it. . I think the Pascal way is the best where a pointer would be declared like this: p: ^integer;. This is very clear in my mind, as it reads "p is a pointer to an integer. int* p or int *p, they both read backwards to me, I just put it next to the variable name because that's where it's going to be when I dereference the pointer, so I might as well be consistent in my declarations as well.
19. Re:The Internet is based on C by DMFNR · 2011-11-13 17:30 · Score: 2
  
  Actually during the creation of NT Microsoft licensed a network stack from Spyder Systems, which was based on the BSD TCP/IP stack. Microsoft replaced this with it's own stack for NT 3.5, which was the second version, and I believe that was the one that went in to Windows 95. Some small userland utilities persisted after the stack was replaced, and who knows how much BSD code Microsofts own network stack contains even to this day seeing as we can't review Microsoft's source. Not that it really matters, as the BSD license doesn't require them to release the source, just to provide credit to the original developers, and I know these were present in some of the utilities at least up to XP, and I'm sure if the included any BSD code in their current network stack they would have the attribution hidden somewhere in fine unreadable print.
20. Re:The Internet is based on C by drsmithy · 2011-11-13 17:34 · Score: 1
  
  Firstly, Windows NT (ie: contemporary Windows) was designed and built from day 1 as a multiuser OS.
  Secondly, also from day 1, it has had a far more comprehensive and capable security infrastructure than traditional UNIX.
  Thirdly, UNIX was originally built as a single-user OS. Multiuser capability was added (soon) afterwards. One rather visible aspect of this is the presence of a superuser (root).
  You are wrong about pretty much everything you've written.
21. Re:The Internet is based on C by DMFNR · 2011-11-13 18:28 · Score: 1
  
  You liar! I can't find the swimming pool anywhere in Solaris, BSD, or Linux!
22. Re:The Internet is based on C by bertok · 2011-11-13 19:18 · Score: 1
  
  O_o
  Oh my god! This is why I'm not ever going back to C/C++ unless forced to at gunpoint.
23. Re:The Internet is based on C by martin-boundary · 2011-11-13 20:06 · Score: 1
  
  Wrong. On account of backwards compatibility, the available infrastructure was never seriously enforced, and on account of idiotic security flag combinations the options available did not promote real security.
  XP SP2 was the first time a (laughable) effort was actually made to enforce some security. With SP2, enforcing security on sensitive API calls meant something trivial like inserting a pop up dialog box to ask the user for confirmation. All you had to do to bypass it was send a button click message to that window's message pump, no user interaction required!
  But the problems lie much deeper. For example, CreateFile has a lot of access flags, but it's such a boneheaded system that the only hassle free way to allow more than one process to read/write the same file concurrently is to always open the file with the strongest access rights available. That's because once a file is open, the next process that tries to open it can't override the existing access modes. Crazy, eh?
  That's like having a door with a fancy biometric hand sensor but now your friend can't walk through it at the same time as you, because his DNA isn't compatible with yours. So you either walk through the door one person at a time and close it/reopen it halfway through, or the first person to get to the sensor disables the DNA checks so you can both walk through together.
  MSDN is full of impressive sounding security systems that programmers do their best to ignore, because they're unusable.
24. Re:The Internet is based on C by martin-boundary · 2011-11-13 20:14 · Score: 2
  
  Actually, I think I fucked that one up. The bit size is exact, but there is no guarantee that the typedef for a particular size exists, so technically you can't rely on uint16_t in your programs anyway.
  The people on the standards committes are either saints, or abject evil scum. Maybe they're in a quantum superposition of both states, as long as you don't open the ISO report and take a look...
25. Re:The Internet is based on C by dkf · 2011-11-13 21:04 · Score: 1
  
  Actually during the creation of NT Microsoft licensed a network stack from Spyder Systems, which was based on the BSD TCP/IP stack. Microsoft replaced this with it's own stack for NT 3.5, which was the second version, and I believe that was the one that went in to Windows 95.
  More to the point, you can still see the heritage in the C API; it's recognizably similar throughout despite many other parts (e.g., file descriptors) being wildly different between Win and Unix. That's OK too. It means that Microsoft have a properly road-tested API in use. (The code itself may have gone, but that would be No Big Deal. While some C code really does survive for multiple decades, it's not really to be expected in any OS. APIs are much longer-lived.)
  
  --
  "Little does he know, but there is no 'I' in 'Idiot'!"
26. Re:The Internet is based on C by shutdown+-p+now · 2011-11-13 22:32 · Score: 1
  
  I hate "long long"
  
  This dates back to Algol 68. In Algol, the basic numeric data types were INT and REAL, and you could prepend an arbitrary number of SHORT or LONG to them. Any implementation was guaranteed to support SHORT INT and LONG INT as distinct data types, respectively smaller and larger than INT, but any extra prefixes were conditionally supported - it was always legal to write, but it was implementation-defined whether e.g. LONG LONG INT is larger than LONG INT, or the same. I think it's a fairly interesting convention, which would have scaled nicely to 64-bit and 128-bit if C implementations actually adhered to it.
  Anyway, "long" is the obvious opposite of "short". If you want "wide int", the other would have to be "narrow int".
  
  better yet, you should be able to explicitly state the width of data types
  There's stdint.h for predefined commonly-used stuff, and bitfields for the more exotic things like 17-bit integers.
  
  "bool" doesn't work right.
  What about it?
  
  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.
  Regardless of what you think about it, the way it is parsed in either C or C++ is by attaching * to variable name, so it's perfectly logical to format it accordingly. In fact, one could argue that formatting it the way you want would be lying about how it actually works.
  It would be more logical to argue that C is wrong in that it parses things like that, and I would even agree. But we have what we have.
27. Re:The Internet is based on C by shutdown+-p+now · 2011-11-13 22:36 · Score: 1
  
  The reason why there's no guarantee is because there are actual real-world architectures on which it would be impossible to uphold such a guarantee (at least in a reasonably efficient way). E.g. SHARC only has 32-bit words, so implementing an int16_t would be kinda tricky - sure, the compiler could do it with bitwise operations, but think about how a pointer to int16_t would look, and how dereferencing operation would work.
  In practice, if you need intN_t, you'll probably just assume that it's available, and your program will work correctly on any implementation that provides it (i.e. all the sane ones). Beside that, if you need intN_t on all possible architectures, and you don't care about the potential perf hit it might take to use one, just use a bitfield of size N.
28. Re:The Internet is based on C by ledow · 2011-11-13 23:32 · Score: 1
  
  If style issues bother you, run your code through a styler before and after you receive them from your source-code management system.
  Really, style and content in C are as separate as they are in HTML and CSS. If you want a certain way of spacing things, generate a rule that turns everything into your style before you see it and converts back to whatever the agreed style is before you publish it for others. It really makes no difference to the compiler, only the programmer. And the programmer that can't even set up a simple code-styler is the one who should be shot or (more likely) sacked.
  My Eclipse C IDE setup is perfectly set to the settings that I want and use. Other people hate it. I like my loop braces on completely independent lines (so if and condition are on line 1, loop brace on line 2, loop content on the next few lines, loop brace on next line, else statement - possibly with condition on next line, loop brace on next line, "else" content and then loop brace on a final line), I use the double-slash comment syntax for multi-line comments (and reserve the star-slash syntax for when I'm commenting out a block of code), I tab indent everything but it's really a four-space indent each time, I enclose each case blocks in switches statements with curly-quotes, I like spaces in between every function parameter and even either side of any assignment-equals, and a million and one other "crimes" that some people don't like. My code is still C99, though, and takes seconds to reapply formatting style to whatever you want if you have a decent IDE or SCM.
  Personally, I always keep the * with the variable - because that is what it applies to. It's nothing to do with the int, that's just the contents of it (you "read" pointers from right to left - int * is a pointer to an int, int ** is a pointer to a pointer to an int), but the fact it's a pointer is a million times more important not to get confused (and as the poster above explains, it's easy to do). Yes, your compiler should catch most stupidity but relying on your compiler to spot your stupidity is stupidity in itself.
  As soon as you start getting into double-pointers (**), then you generate a world of hurt for yourself by trying to keep them with the type. I always think of pointers as *entirely* different things to variables because you can have a pointer to a range of different types beyond the built-in types, but something is either a pointer, or not a pointer and changing it requires a particular keyword (& or *). The * is a special indicator of this unique property and should follow the variable, not the type.
  I also prefer:
  void *function_name(int parameter)
  even though:
  void* function_name(int parameter)
  is perfectly legal. Strangely, I see a lot of programmers who write variable pointers differently to functions that return a pointer, etc. And don't even get me started on what happens when you have a function pointer to a function that returns a pointer of some kind (which I most commonly hit when loading DLL's dynamically and trying not to stomp over declarations in the library header files that would require linking the static library to work without interfering). There's all sorts of hideous choices that can be made there.
29. Re:The Internet is based on C by BenoitRen · 2011-11-14 00:16 · Score: 1
  
  As soon as your computer is infected, you've lost. No amount of local security can change that.
  
  Windows + Internet = insecure.
  
  No, Windows + Internet + compromisable network services or IE = insecure. Using Windows to browse the web using TCP/IP and an alternative web browser is as good as secure.
30. Re:The Internet is based on C by Anonymous Coward · 2011-11-14 02:08 · Score: 0
  
  No, every bit you send and receive is an arrangement of logic states (HI/LO voltages) held in hardware who's instructions and data, processed by special purpose machines (powered arrangements of transistors forming "gates"[Gill Gates, hmmm... that IS weird]), travels along "buses" (wires) based on the patterns (varying state of each bus line or input/output path) supplied to these machines (chips/ICs). The C language is just another convenient abstraction of this crazy little world.
31. Re:The Internet is based on C by Toonol · 2011-11-14 04:04 · Score: 1
  
  And uint16_t is ugly. It's as ugly as all the other fixes that have been applied post-facto to C. C really needed a redesign, not an expansion.
32. Re:The Internet is based on C by tlhIngan · 2011-11-14 05:15 · Score: 1
  
  Actually, Windows NT had better security than Unix.
  The problem was, the legacy Windows systems had NO security. When developers are under the assumptions that they're on a single-user machine, running basically as administrator, it doesn't bode well for security when you try to run the same program under a more secure OS.
  Since no one would move to NT if it didn't run their crap-programmed software, Microsoft had to basically disable security in order to get compatibility.
  We see this in several places. First, Mac OS X 10.4 supported "fast user switching". Guess what? A bunch of Mac apps broke because they assumed one user to one Mac and there would never be two people simultaneously logged in.
  Windows went through this as well - there were apps that couldn't run in anything but Session 0.
  Next, you try redoing security again, and you have Vista. Which broke a TON of applications because Vista locked things down. In fact, that's what gave Vista its black eye - everyone thought it broke everything so stayed away. Basically Microsoft gave developers an ultimatum, and the developers decided to screw off. Microsoft made it just hard enough to revert to XP that people eventually lived with it. 7 basically came out 2 years later after the dust settled and developers actually decided to fix their software. Microsoft could've re-released Vista as 7.
  Take away - developers suck, and the need to "get it working" often leads to shortcuts that screw everyone in the end. (Lots of programs have "C:\Program Files\" hardcoded into them, so if your system disk is another partition, or if you're using another language...)
  Apple's method is to say if you don't use things as documented, you're on your own, so naturally tons of things break every release as Apple restructures private APIs and such.
  Microsoft's method is to ensure compatibility because people will blame Windows for breaking stuff. It's why the root desktop window is still called Program Manager. Or why Windows has to make the system drive C:\ even though it would've been called D/E/F/etc normally.
33. Re:The Internet is based on C by djdanlib · 2011-11-14 08:38 · Score: 1
  
  That is to say, when all you have is a hammer, you can easily shoot yourself in the foot.
  That's a delightful metaphor you have there. I may have to appropriate it if you don't mind.
34. Re:The Internet is based on C by chrismcb · 2011-11-14 11:25 · Score: 1
  
  - 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.
  People who put the * next to the type are the ones who should be shot.
  int* a, b;
  int *a, b;
One word, fuckhead... by Anonymous Coward · 2011-11-13 08:18 · Score: 1

Contractor.
web programming has ruled this contest obsolete by Anonymous Coward · 2011-11-13 08:30 · Score: 1

have you seen a designer's php code??
Platforms that can't run C by tepples · 2011-11-13 08:31 · Score: 2

The kind of crap that would be easier to rewrite than refactor?

How about stuff that needs to be rewritten from scratch because a target platform can't run C? This is true of the web (or at least it was until Emscripten), and it's still true of Xbox Live Indie Games and Windows Phone 7.
Replace it with the American Management by Anonymous Coward · 2011-11-13 08:50 · Score: 0

Direction Obfuscation Test.
Am I the only one, but are our bosses not understanding Dilbert? I've got one who thinks it's about managers talking to dumb employees.
This ties nicely into the previous story, Is American Innovation Losing It.
1. Re:Replace it with the American Management by fsckmnky · 2011-11-13 09:41 · Score: 1
  
  You aren't the only one. I posted a comment about how it'd be nice to have a contest awarding excellent C programming practices, and I'm getting flamed for bashing the IOCCC contest, the C language, open source, closed source, peoples grandmothers, sliced bread, etc. Go figure.
2. Re:Replace it with the American Management by Anonymous Coward · 2011-11-13 09:48 · Score: 0, Offtopic
  
  My grandmother was killed by sliced bread, you insensitive clod!
Perl IOCCC by Billly+Gates · 2011-11-13 10:05 · Score: 1

That way we can submit hello world programs that make the C IOCCC ones look like a picnic

--
http://saveie6.com/
Oh no, someone obfuscated IOCCC for 5 years by youn · 2011-11-13 10:36 · Score: 1

but I am happy it is back

--
Never antropomorphize computers, they do not like that :p
Because D is such a heavily used language... by Anonymous Coward · 2011-11-13 11:50 · Score: 5, Insightful

A number of quick points... Some people just don't know, so here are some practical speaking points...
-C has been around longer than most of the non-C programmers alive. That includes you people on this site, which has the smartest people, from one of the most divisive areas in the civil space: the "tech wars".
-D was such a better language... also, C++ because we never hear about C anymore.
-Java is on it's way out, being deprecated by the largest company in the world, which also deprecated Flash (on mobile) which Adobe just acquiesced to, replaced by Google's new iteration. Maybe not in the next 5 years, but it can no longer grow... it will have to get smaller with less support.
-Objective-C, used by Apple Inc., the largest company in the world, is a wholly-compatible superset of (ANSI) C. There are no signs of change here. Big surprise, it's all the same hardware components, just in larger capacities, at faster rates, and smaller form-factor. C can't help us with the flux capacitor... but that has not been added to the standard CPU, memory, memory storage, etc. model.
-Google announced that Android will run a C-like-language in the native space that uses the CPU and GPU. Even with Dart coming our way...
-CUDA... C is relevant in other (all) GPU spaces which is the go-to-guy, for the moment, to eak out more performance from a machine.
-And here is where the feelings get hurt: In college, I strattled the EE/CS line while being firmly EE. EEs learn C because it teaches them valuable things about the hardware, being a very light obfuscation. CS departments tend to concentrate on, well, anything else. Flavors of the year, interesting projects, etc. That is their place. My older brother went the CS route, 8 years before I got my turn and went EE. I admire him and his success greatly but I know, push came to shove, I can talk about certain topics without talking about garbage collectors and universal typing.
So, please, if you've never used C in any significant way, just don't comment. Listen. People, young and old, have something to tell you about the most significant programming language ever invented.
And to bring this all together: When you are trying to eke out CPU cycles so your 3D rendering is above 60 fps on that mobile device, you will know why closeness to hardware and C, in particular, may be your best friend. Or a C-like language...
Another way to look at it: People who know C and have worked with it, can't just unknown it. They know what you non-C people know, but also have other experience. If MOST of them say C is indispensable, then how about you do the one thing some Tech Asshole never do: Take someone else's advice. And STFU.
Can we just talk about something else that is awesome and not caught up in this stupid argument?
1. Re:Because D is such a heavily used language... by Anonymous Coward · 2011-11-13 12:14 · Score: 3, Funny
  
  People, young and old, have something to tell you about the most significant programming language ever invented.
  You mean LISP? I haven't seen anyone mention it yet.
2. Re:Because D is such a heavily used language... by Anonymous Coward · 2011-11-13 13:19 · Score: 0
  
  Asking people to not get caught up in stupid arguments, is a lot like asking 1st graders to pass high school level reading comprehension class. It almost never happens.
3. Re:Because D is such a heavily used language... by Anonymous Coward · 2011-11-13 17:51 · Score: 0
  
  Yes he means Lisp, he's just too holier than us to realize.
4. Re:Because D is such a heavily used language... by JasterBobaMereel · 2011-11-13 21:02 · Score: 1
  
  Remember that most modern languages had their compilers or interpreters written in C (even if they are now self compiled), or often now Java ... and the JVM and compiler is written in C ...
  
  --
  Puteulanus fenestra mortis
5. Re:Because D is such a heavily used language... by Anonymous Coward · 2011-11-13 22:10 · Score: 0
  
  People have been predicting Java's demise for almost 10 years now. Between it's huge enterprise base and Android, it is not going anywhere.
6. Re:Because D is such a heavily used language... by Anonymous Coward · 2011-11-14 02:35 · Score: 0
  
  "Can we just talk about something else that is awesome and not caught up in this stupid argument?"....I don't know God, I think your rant pretty much ruined that. The invectim you dribble forth sounds like someone with a narrow view and limited understanding still. The C language is just a sensical way of taking the pain out of assembly or binary/hex programming--the first painless rung up from flipping physical switches on a data/address bus. It is a simple natural progression, nothing more. the fact that people get into arguments about it shows they know nothing. Just ignore them.
7. Re:Because D is such a heavily used language... by Smallpond · 2011-11-14 09:30 · Score: 1
  
  Looking at Monster today I see someone is looking for a Fortran programmer.
My favorite IOCCC winning entry by chocapix · 2011-11-13 20:47 · Score: 1

We've all coded a quine, but this goes at least three steps further. Documentation here.
I am so looking forward to reading the 2012 winning entries!
You people have no clue by Anonymous Coward · 2011-11-14 02:14 · Score: 0

To understand what this is about go look up the pig latin translater.
This compiles and actually works:
http://www.cise.ufl.edu/~manuel/obfuscate/piglatin
Perl.. by bored · 2011-11-14 03:51 · Score: 2

I can't believe no one has mentioned this yet!
But, before perl, what was Larry Wall famous for?
Winning the IOCCC, not once, but twice.
Makes you think...
1. Re:Perl.. by Anonymous Coward · 2011-11-14 09:00 · Score: 0
  
  I didn't know this, but it all makes sense now!
Uh... by Anonymous Coward · 2011-11-14 05:49 · Score: 0

someone writes broken Java code and that's somehow an indictment of the language?
Oh, and there are very good reasons for StringBuilder. Strings are immutable in Java and StringBuilder is a simple way to avoid quadratic complexity when building strings (as naive copying + "appending" would). Not sure why they didn't go with ropes, though...