Timeline for Is an empty 'while' loop bad practice?
Current License: CC BY-SA 4.0
18 events
| when toggle format | what | by | license | comment | |
|---|---|---|---|---|---|
| Dec 1, 2020 at 22:21 | comment | added | supercat | @BenVoigt: Nearly all non-contrived non-trivial C programs would be zero characters away from UB given a sufficiently obtuse reading of the Standard. | |
| Dec 1, 2020 at 22:03 | comment | added | Ben Voigt |
@MarioCarneiro: let the number of "neighboring" UB programs be K and the length of the program be N, then maximize K / pow(N, 1 + a)... otherwise you can take any "fragile" sequence and just duplicate it in a new scope an arbitrary number of times to increase K arbitrarily. Also I think you want to use Levenshtein (edit distance) not Hamming distance, as the initial example here involved a deletion && -> & not a substitution
|
|
| Dec 1, 2020 at 21:16 | comment | added | Mario Carneiro | @BenVoigt That sounds like an interesting code golf challenge: find a C++ program with hamming distance 1 to the most number of UB programs. :) | |
| Dec 1, 2020 at 17:53 | comment | added | Ben Voigt | @MarioCarneiro: Most code is literally one character away from undefined behavior. | |
| Nov 30, 2020 at 19:37 | comment | added | Asteroids With Wings | @MarioCarneiro So you did :) | |
| Nov 30, 2020 at 17:40 | comment | added | Mario Carneiro | @AsteroidsWithWings I'm not endorsing the practice, but it does exist. As for "looks like a typo", well (1) that depends entirely on what you are habitually exposed to and (2) it very well may be a typo, and as pointed out a pretty bad one in this case. The combination of control flow and mutation in a single statement makes the code very tricky and literally one character away from UB. It smells very much like "clever" code. As for "refactor your code flow"... I did. That's literally the point of my original comment. | |
| Nov 30, 2020 at 15:23 | comment | added | Asteroids With Wings | @MarioCarneiro That sort of micro-optimisation is a poor way to code. A bitwise & in a conditional looks like a typo. If you're concerned about short-circuiting, refactor your code flow to avoid it. Use bitwise & for..... bitwise operations! | |
| Nov 30, 2020 at 3:30 | comment | added | Mario Carneiro |
@AsteroidsWithWings Sometimes people use the & operator on boolean values in a conditional to deliberately avoid the short-circuiting behavior, because it can be faster in some cases than a branch. @ Dedup, It's not about banning boolean logic, it's trying to separate the part of the code where answer is not known to be valid from the part where it is. The fact that validate_answer is not called unless err = 0 is essential here, so it makes sense to handle that completely before you start talking about answer as if it were valid.
|
|
| Nov 29, 2020 at 22:27 | comment | added | Asteroids With Wings | @MarioCarneiro Why would anyone switch to bitwise AND there? | |
| Nov 29, 2020 at 21:27 | comment | added | Deduplicator | @MarioCarneiro I'm sorry, but banning boolean logic? Not with me. Also, much code, even side-effect-free code, depends on short-circuiting. Knowing the basics of the language one uses is necessary if one wants to get anywhere beyond copying "hello world"-programs. | |
| Nov 29, 2020 at 19:44 | comment | added | Mario Carneiro |
Also the data dependency from one condition to the second is really sketchy; most probably don't know that if you use the non-short circuiting & instead of && you would get undefined behavior because of the unsequenced data race. Better to be explicit about that sort of thing.
|
|
| Nov 29, 2020 at 19:42 | comment | added | Mario Carneiro |
@Deduplicator I do, as I mentioned you shouldn't be just breaking on that anyway since that mixes up an IO error with a valid answer, which seems bad. To replicate that code's behavior you could write int err = getline(cin, answer); if (err) break; if (!validate_answer(answer)) break; and there are a variety of ways to compress that depending on requirements. But you should probably do something about err in the first break and the original version makes it difficult to handle the error.
|
|
| Nov 29, 2020 at 18:13 | comment | added | Deduplicator | @MarioCarneiro You know that doesn't have the same semantics? Specifically, it doesn't check for input error, like end of input. | |
| Nov 29, 2020 at 17:41 | comment | added | Mario Carneiro |
I would prefer to see something like loop { std::getline(std::cin, answer); if (validate_answer(answer)) break; } or using a do-while loop. Effectful functions in conditionals are difficult to reason about. (You probably want to do something besides just break if std::getline fails anyway.)
|
|
| Nov 29, 2020 at 14:36 | comment | added | Deduplicator |
@freakish Ok, I'll bite. How should it look? And remember to stay efficient. Anyway, there are others if you don't like std::getline, it doesn't depend on this one function.
|
|
| Nov 29, 2020 at 13:57 | comment | added | freakish | One could simply argue that std::getline is poorly designed, which I agree with. It is irrelevant that it is a part of the standard C++ library, which automatically makes it popular. Popular != perfectly fine abstraction. | |
| Nov 29, 2020 at 0:48 | history | edited | Deduplicator | CC BY-SA 4.0 |
edited body
|
| Nov 29, 2020 at 0:12 | history | answered | Deduplicator | CC BY-SA 4.0 |