Layouteditor macro boolean operators6/14/2023 ![]() You'll often find some of these "bad examples" in production code, and many experienced programmers swear by them: they work, some are shorter than their (pedantically?) correct alternatives, and the idioms are almost universally recognized. If (!ptr) // Sleazy, but short and valid. If (ptr = NULL) // Perfect: compares pointers. Return (x > 0) // Simpler, clearer, correct. Return (x > 0) ? TRUE : FALSE // You're fired. Similarly: if (someBoolValue = FALSE) // Redundant. Or // Better: lingustically clear, compiler will optimize. The right way to do this is either // Valid, but still treats int as bool. So the line above returns TRUE only when yourString > myString. That's because the return value of strcmp() is That looks legitimate, and the compiler will happily accept it, but it probably doesn't do what you'd want. ![]() ![]() So, for example, it's perfectly legal to write if (strcmp(yourString, myString) = TRUE) // Wrong!!! They aren't the same, but compilers generally allow it. Why? Because many programmers use the shortcut of treating ints as bools. If (otherValue != TRUE) // Whatever you do, don't do this! Examples: if (thisValue = FALSE) // Don't do this! Given the de facto rules that zero is interpreted as FALSE and any non-zero value is interpreted as TRUE, you should never compare boolean-looking expressions to TRUE or FALSE. A side effect of this is that a value like 5 evaluates to TRUE, but NOT 5 evaluates to -6, which is also TRUE! Finding this sort of bug is not fun. Their NOT operation was implemented by adding 1 and flipping the sign, because it was efficient to do it that way. Like many modern languages, they interpreted any non-zero value as TRUE, but they evaluated boolean expressions that were true as -1. Some BASICs defined FALSE as 0 and TRUE as -1. But by letting the compiler define TRUE and FALSE according to its own rules, you're making their meanings explicit to programmers, and you're guaranteeing consistency within your program and any other library (assuming the other library follows C standards. Granted, in C, (1 2) evaluates to 0, so as others have said, there's no practical difference as far as the compiler is concerned. ![]() What is important is that a statement like if (1 2) evaluates to if (FALSE). The numeric values of TRUE and FALSE aren't important. You just make your code harder to understand and maintain for other C programmers.The answer is portability. Resist the urge to create macros for standard delimiters and operators. Then an experienced C programmer comes in, says "what's all this garbage", and rips it all out anyway, like I wound up doing after the situation I described above. The problem is no two programmers do it the same way, and you just wind up with an unmaintainable mess. Straight C code can be a bit eye-stabby, and generations of programmers have tried to use the preprocessor to redefine operators or delimiters to something easier to read (such as Pascal programmers redefining as BEGIN and END, Fortran programmers redefining & and || to AND and OR, etc.). It is not common practice, and in my experience it creates maintenance problems (such as doing a global search and replace to change an "and" to an "or" in several string literals and breaking code because someone else decided to use and instead of & and or instead of ||). and also if it has any side effects, I would be grateful. If anyone can direct me is this bad or good practice, is it common etc.
0 Comments
Leave a Reply. |