5 ms·
I agree on the "I would never write code like this" point. I have never read the C standard and don't know off the top of my head what happens when you fail to
by pwaring 15y ago
I agree on the "I would never write code like this" point. I have never read the C standard and don't know off the top of my head what happens when you fail to initialise a static vs auto variable, but I don't really care because I would never write code which relies on whatever the implicit behaviour is. If I found code which did that on a project I'm involved with, I'd search for what is supposed to happen and then fix the code to make it explicit.
If I was interviewing, I'd much rather hire someone who said "I'd never write code like that" to someone who reels off what might happen in every possible scenario, unless I was hiring for a compiler writer.
- mnutt 15y agoKnowing what happens when you fail to initialize a static variable may be useful for debugging when you (or someone else) accidentally fails to initialize a static variable.
- astrange 15y agoWell, you can't fail to initialize a static variable, so maybe you meant accidentally initializing it to the wrong value.
- mquander 15y agoI disagree. I feel that knowing what might happen demonstrates that the individual has considered the design of C carefully and taken the time to find out how it is, and why it is the way it is. I think that sort of knowledge always leads to better code in the language. The man in the example might know to "never write code like" a variable incrementing and assigning to itself again, but there might be other, more subtle pitfalls in design and implementation that he succumbs to because he hasn't given much thought to all the different ways that the rules of the language can interact.
- philh 15y agoI agree - the girl's knowledge might be a net win, provided she doesn't go out of her way to use it. Note that it's not all stuff that you can just look up: although you can look it up, it might not be obvious that it needs to be looked up. I had no idea there was a difference between `int f()` and `int f (void)`, and if that ever caused problems for me I doubt I would have been able to track it down easily. "A gentleman is someone who knows how to play the bagpipes, and doesn't."
- sirclueless 15y agoSure, but would you really care whether someone knew off the top of their head that %zu is the escape sequence for size_t? Some of the stuff she shows off is pretty arcane, though pieces of it are actually useful. Understanding the memory model and execution model is a big plus, because it lets you write correct and efficient code (and if you are using C you care about correctness and efficiency). Recalling arcana about the C99 standard is just overkill and asking someone to pull stuff like that out of a hat in an interview is asking too much IMO.
- pwaring 15y agoIf you're being sensible and using -Wall with gcc, it will pick up the %zu thing anyway: sizeof-test.c: In function ‘main’: sizeof-test.c:5:3: warning: format ‘%d’ expects type ‘int’, but argument 2 has type ‘long unsigned int’ Compilers have warnings so that you don't have to remember archaic bits of C. :)
- numeromancer 15y agoYes, I would care. Someone who didn't know might notice the sizeof() and note that it returns size_t, but not know what to do about it, and end up saying "screw it" and just using "%d", which is not portable, and the program might crash when compiled for a different system. It might even run on his sytem today, but not tomorow, or run in the debug image but fail in production. I've seen this and similar things happen many-a-time.
- unwind 15y agoPet peeve alert: sizeof is not a function. It's a unary operator. The parenthesis you usually see after it are part of the argument, which for type names looks like a cast to the type in question. Like any other cast, the syntax is the type name in parenthesis. Apologies if you already knew this.
- yxhuvud 15y agoLearning arcane trivia is a side effect of learning the necessary stuff.
- wildjim 15y agoI agree. It's a little like a Java programmer knowing JVM bytecode: definitely not _needed_ but you'll be much better at understanding why (for example) some code structs are more efficient than others.