Earlier quoted context omitted.
I believe DriverKit is still C++.
...and of course pre-Apple, DriverKit was Objective-C.
So you think you know C? (2016)
231–240 of 344 posts
Re: So you think you know C? (2016)
#232Re: So you think you know C? (2016)
#233Earlier quoted context omitted.
Because when you work on a team, not everyone is a C Gandalf, probably not even yourself a couple of months later when fixing a bug with everyone screaming that the system is down. Exaggerating here, but rule of thumb is that it takes twice to debug as it takes to write it, so how long do you want to take to do maintenance fixes?
rule of thumb is that it takes twice to debug as it takes to write it Ok, so... macros which let me write code faster should help with debugging time as well? ;-)
So it depends how complex they are.
Re: So you think you know C? (2016)
#234Re: So you think you know C? (2016)
#235Well, that's a copout. Of course, if you take absolutely any computer architecture, you can't assume simple things like sizeof(int) or data structure alignment. But if sizeof(int) is at 4 and data needs to be aligned by its own size - like on any real architecture relevant today - many of these questions have a deterministic answer. In practice, compiler bugs are a much bigger issue than architecture assumptions.
Re: So you think you know C? (2016)
#236Re: So you think you know C? (2016)
#237Earlier quoted context omitted.
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…
Re: So you think you know C? (2016)
#238Earlier quoted context omitted.
Could you go into a little bit more detail regarding the movzx? Aren't 32-bit registers always zero-extended on x86-64?
Sure. Here's an in-depth explanation from Fabian Giesen: https://gist.github.com/rygorous/e0f055bfb74e3d5f0af20690759...
Re: So you think you know C? (2016)
#239Earlier quoted context omitted.
The questions are a bit cute, but they’re not testing obscure corner cases of the language. It’s not like asking if you have the trigraphs memorized. It’s testing fundamental rules about how C works: overflow, integer promotion, order of operations, memory layout, etc.
They're all obscure in a "I wouldn't write code like that or let it go through review" sense. They're very synthetic cases.
Re: So you think you know C? (2016)
#240There are a few problems with the questionnaire. "I don't know" is pretty generic choice to be given/choosen. Say for example, in question 5, the statement "return i++ + ++i;" is undefined, because the value of i is read and modified twice in a single sequence point (and of course, the order of addition is unspecified), which is not allowed in C. So the answer is "Undefined." (The explanation given in the page not ac…
To me "I don't know" is a very apt choice. It makes the point clear that indeed reading the code does not allow you to know the result, which is quite a pitfall. In your comment you are jumping from "I don't know", which is the first step, to wanting to explain why.