3 ms·

This reminds of me of the Quiz books that were popular years ago. They'd show some code that inadvertently tripped some obscure corner of the language. Rarely

This reminds of me of the Quiz books that were popular years ago. They'd show some code that inadvertently tripped some obscure corner of the language. Rarely did the quizzes provide great insight. Rather, they confirmed the benefits of keeping your code idiomatic.

weland 12y ago
It's pretty much what pops into my head every time I see things like these. I got most of those correct, but my universal reaction was why the hell would I write something like that in the first place?
- ben0x539 12y ago
  I figure a lot of the time, you don't write it like that, but you get weird behavior in a much more complicated situation without obvious defects that eventually can be reduced to an example that would fit in with those quizzes.
  - weland 12y ago
    I don't remember any of that, either. The worst I've ever had was a silly bug due to operator precedence. Barring some truly uninspired things (like signed integer overflow being undefined), I really think most of those are cases one shouldn't run into, not even in a much more complicated situation.
    - JoeAltmaier 12y ago
      Many of the complicated situations arise from macros and templates that use arguments in contexts the coder doesn't know. E.g. the stl. Also the macro writer doesn't know the context wherein the macro will be expanded. You can end up with issues of precedence, correct statement construction, expression evaluation order etc.
      - weland 12y ago
        STL is not a problem in C land and fishy macros don't make it past code review in my book :-). I don't disagree on the usefulness of teasing your brain with these things once in a while. However, I think the best way to ensure you don't hit bugs caused by such things is to avoid the situation altogether.
        JoeAltmaier 12y ago
        It doesn't have to be a very fishy macro at all to be problematic. How about #define Sum(a,b) a+b This of course fails in any context where the precedence of '+' doesn't match your intent e.g. Sum(1,5)7 becomes 1+57 Do you remember to always define your expression macros with parentheses? Any time you didn't do that, you have a bug.
        lmm 12y ago
        > Do you remember to always define your expression macros with parentheses? Yes - that's a necessary part of being idiomatic. Any macro that's defined without brackets sticks out like a sore thumb, and won't pass code review, even if it's (initially) used in a place where they wouldn't be necessary.
        weland 12y ago
        > Do you remember to always define your expression macros with parentheses? Oh, yes! No parentheses around elements of a macro definition is an obvious sound of trouble and looks very wrong on my retina. I do agree, though, that if I somehow forgot to do that (tired? nervous?), that would be a bug that's difficult to spot. Point taken :). That's what code reviews are for, but there isn't always time or availability for one, sadly.
cbsmith 12y ago
Sadly, much of this code is idiomatic.
bnastic 12y ago
Quiz books, or more often - Brainbench

weland 12y ago

It's pretty much what pops into my head every time I see things like these. I got most of those correct, but my universal reaction was why the hell would I write something like that in the first place?

ben0x539 12y ago
I figure a lot of the time, you don't write it like that, but you get weird behavior in a much more complicated situation without obvious defects that eventually can be reduced to an example that would fit in with those quizzes.
- weland 12y ago
  I don't remember any of that, either. The worst I've ever had was a silly bug due to operator precedence. Barring some truly uninspired things (like signed integer overflow being undefined), I really think most of those are cases one shouldn't run into, not even in a much more complicated situation.
  - JoeAltmaier 12y ago
    Many of the complicated situations arise from macros and templates that use arguments in contexts the coder doesn't know. E.g. the stl. Also the macro writer doesn't know the context wherein the macro will be expanded. You can end up with issues of precedence, correct statement construction, expression evaluation order etc.
    - weland 12y ago
      STL is not a problem in C land and fishy macros don't make it past code review in my book :-). I don't disagree on the usefulness of teasing your brain with these things once in a while. However, I think the best way to ensure you don't hit bugs caused by such things is to avoid the situation altogether.
      - JoeAltmaier 12y ago
        It doesn't have to be a very fishy macro at all to be problematic. How about #define Sum(a,b) a+b This of course fails in any context where the precedence of '+' doesn't match your intent e.g. Sum(1,5)7 becomes 1+57 Do you remember to always define your expression macros with parentheses? Any time you didn't do that, you have a bug.
        lmm 12y ago
        > Do you remember to always define your expression macros with parentheses? Yes - that's a necessary part of being idiomatic. Any macro that's defined without brackets sticks out like a sore thumb, and won't pass code review, even if it's (initially) used in a place where they wouldn't be necessary.
        weland 12y ago
        > Do you remember to always define your expression macros with parentheses? Oh, yes! No parentheses around elements of a macro definition is an obvious sound of trouble and looks very wrong on my retina. I do agree, though, that if I somehow forgot to do that (tired? nervous?), that would be a bug that's difficult to spot. Point taken :). That's what code reviews are for, but there isn't always time or availability for one, sadly.

cbsmith 12y ago

Sadly, much of this code is idiomatic.

bnastic 12y ago

Quiz books, or more often - Brainbench