3 ms·

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 inte

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

by weland 12y ago

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.