I failed on one, number 4. I bravely assumed 16 bit integers cannot exist. Can anyone name a concrete platform/compiler where int is/was 16 bit. Or is this just a theoretical option left open by the spec?
pdp-11
So you think you know C? (2016)
211–220 of 344 posts
Re: So you think you know C? (2016)
#212Earlier quoted context omitted.
And then you update your compiler and something completely different happens.
Or your standards conforming but mischievous compiler does something nondeterministic ;)
1) This made me curious. Are any of the compilers in real use nondeterministic?
2) Probably that's not needed? A normal optimizing compiler just inlines the function somewhere new — and boom? Then again, can that really happen with practical contemporary compilers and this exact statement?
Re: So you think you know C? (2016)
#213Earlier quoted context omitted.
> My C/C++ code is as boring as possible. One advantage to being an older programmer is I don't feel any need to show off any more. I try to make it so obvious that anyone would look at it and think that's so simple, anyone could do it. It's surprisingly hard to write simple code. Any idjit can come up with Rube Goldberg code.
Though different people consider different things simple. To one a loop is fine, to another a map is a better choice.
map/filter/reduce is simpler, but it takes some getting used to. Loops have worn a deep rut in my brain.
Re: So you think you know C? (2016)
#214This is the language we still choose to trust our credit cards with.
I hope you were joking. This is just a "gotcha" quiz and not relevant at all.
Re: So you think you know C? (2016)
#215Having written a conforming C compiler, at one point I knew everything there was to know about C (I forget details now and then, or confusing them with C++ and D). But knowing every engineering detail is not the same thing as knowing how to program in C effectively. It's like being the engineer who designs a Grand Prix car. It does not mean you can drive it faster around the track than anyone else. Not even close. Fo…
Over time I removed all the C preprocessor tricks from my own code and just wrote ordinary C in its place. Much better.
I don't get it. If my macros produce standards-compliant code and they make my code easier to read and understand, why shouldn't I use them?
My goal as a developer is to write clean performant bug-free code... not to make life easy for compiler developers.
Re: So you think you know C? (2016)
#216Can't even make the test. Which version of C? Which platform? Under DOS in the 90's, the answer to the first question would have been 3, it's not even proposed in the options.
Each of the questions has exactly one answer that is correct regardless of version and platform.
It would be correct to answer that I don't have enough information to choose an option. It's incorrect to answer that I don't know.
Re: So you think you know C? (2016)
#217Having written a conforming C compiler, at one point I knew everything there was to know about C (I forget details now and then, or confusing them with C++ and D). But knowing every engineering detail is not the same thing as knowing how to program in C effectively. It's like being the engineer who designs a Grand Prix car. It does not mean you can drive it faster around the track than anyone else. Not even close. Fo…
Over time I removed all the C preprocessor tricks from my own code and just wrote ordinary C in its place. Much better. I don't get it. If my macros produce standards-compliant code and they make my code easier to read and understand, why shouldn't I use them? My goal as a developer is to write clean performant bug-free code... not to make life easy for compiler developers.
> If my macros produce standards-compliant code and they make my code easier to read and understand, why shouldn't I use them?
The problem is they don't make code easier to read and understand. Worse, the unhygienic nature of C macros makes it hard to contain them.
I haven't seen your code, so I'm speaking based on what I've seen of mine and others' code. If you dial it back, the person who has to deal with your code after you leave will appreciate it.
More generally speaking, if you're doing metaprogramming with the C macro system, you've outgrown the language and should consider a more powerful one.
Re: So you think you know C? (2016)
#218Having written a conforming C compiler, at one point I knew everything there was to know about C (I forget details now and then, or confusing them with C++ and D). But knowing every engineering detail is not the same thing as knowing how to program in C effectively. It's like being the engineer who designs a Grand Prix car. It does not mean you can drive it faster around the track than anyone else. Not even close. Fo…
Over time I removed all the C preprocessor tricks from my own code and just wrote ordinary C in its place. Much better. I don't get it. If my macros produce standards-compliant code and they make my code easier to read and understand, why shouldn't I use them? My goal as a developer is to write clean performant bug-free code... not to make life easy for compiler developers.
Can you assure that your preprocessor tricks always generate compliant code?
For me writing embedded code is the ultimate test for your programming skills, since a lot of C toolchains for embedded devices (as in bare metal embedded) are unstable, only almost compliant and full of weird behaviors and hacks.
Re: So you think you know C? (2016)
#219Earlier quoted context omitted.
> So the answer is "Undefined." The code is undefined, but "I don't know." is still the correct answer for what happens to the variable.
No, it isn't. The correct answer to #2 is "According to the standard, the result is implementation defined, but on my target platform, 0". "I don't know" is the wrong answer.
The C specification does not say that undefined behaviour must give a deterministic result on a given platform. All you can say is "this one time I compiled and then ran this code, it gave 0". There is no requirement that the code compiles at all, nor that the same compiler on the same platform produces the same binary on every run, nor that the resulting binary produces the same result on every run, nor that the binary produces any result, nor that it doesn't sometimes produce a result and sometimes not, nor that the compiler doesn't sometimes produces a binary and sometimes not ... undefined behaviour is exactly that: undefined behaviour.
Re: So you think you know C? (2016)
#220It is curious because, in each of the questions I encountered problems with the own questionnaire and I tended to answer in the way the writer thought.
And then you find "it's a trap".
I think the questionnaire is not honest enought, a better answer for D should have been: "we need more information" or "there are programming inconsistences"...
I thought that when selecting "I don't know" I was telling "I don't know what's happening with the code and the inner datails".