Timeline for Why do relational comparison operators never short-circuit?
Current License: CC BY-SA 4.0
15 events
| when toggle format | what | by | license | comment | |
|---|---|---|---|---|---|
| Oct 3, 2023 at 17:25 | comment | added | supercat | @kaya3: The C Standard notes that UB arises, among other things, from non-portable or erroneous constructs, and forbids it only within strictly conforming programs, allowing for the possibility that it may occur in programs that are correct and conforming but not fully portable nor strictly conforming. As for the C++ Standard, it expressly notes that makes no attempt to define any kind of conformance for C programs, and portions of the Standard which appear to specify requirements for programs are intended as shorthand way of expressing requirements for implementations. | |
| Oct 2, 2023 at 18:05 | comment | added | leftaroundabout | @kaya3 "In practice this is hard to track" - yes, side effects are generally hard to track, which is one of the reasons I prefer purely functional programming! In Haskell, changing a <- pop stack; b <- pop stack; if a<=b then... to if pop stack <= pop stack then ... is a type error. | |
| Oct 2, 2023 at 18:02 | vote | accept | CPlus | ||
| Oct 2, 2023 at 17:55 | comment | added | kaya3 | @leftaroundabout Well sure, if you decide that "valid program" means something other than what it normally means then you can claim whatever you like. Your opinion about expressions with multiple side-effectful sub-expressions is noted, though you must also forbid expressions with one side-effect where this affects the value of another sub-expression, such as stack.pop() + stack.size(). In practice this is hard to track and likely forbids too much, but if you really wish for a language that strict then it's none of my business. | |
| Oct 2, 2023 at 17:49 | comment | added | leftaroundabout | @kaya3 well, in a sense programs with UB in them are not valid programs, and should raise a compiler error. This being, again, IMO the right response for an expression stack.pop() <= stack.pop(). Alas, C and C++ compilers don't make an error for every UB, though modern ones are actually fairly good at warning about them. Does that prevent users from writing bad code? -Of course not, but it does prevent them from writing certain kinds of bad code, while not really interfering with any good code. Seems like a win to me. | |
| Oct 2, 2023 at 17:16 | comment | added | kaya3 | @leftaroundabout Languages which don't specify the behaviour of valid programs are confusing and bug-prone; languages which allow users to write bad code are (checks notes) all of them. | |
| Oct 2, 2023 at 9:06 | comment | added | Bergi | @leftaroundabout C++ definitely counts as an "old language like C" :-) | |
| Oct 2, 2023 at 8:49 | comment | added | leftaroundabout | @kaya3 in C++ the order is also not specified (operator <= is not a sequence point). And just because most modern languages specify evaluation left-to-right doesn't mean that this is necessarily a good idea - IMO code where single statements have multiple interdependent side-effects are confusing and bug-prone regardless, so the proper thing is to split them out as two lines, making it clear what's going on. | |
| Oct 1, 2023 at 23:29 | history | edited | kaya3 | CC BY-SA 4.0 | deleted 8 characters in body |
| Oct 1, 2023 at 20:16 | comment | added | EvilSnack | The only way there would be savings without cost is at compile time, if one of the values is a constant maximum or minimum value for its type; then the optimization could be made without run-time cost. There would be no point for a developer to type out an expression like this, but it might result from a macro or some other code generation algorithm. | |
| Oct 1, 2023 at 16:45 | comment | added | kaya3 | @Ángel It may be unspecified in old languages like C, but every modern language I know of specifies left-to-right evaluation order if it matters. I think C should be seen as an outlier in this regard. | |
| Oct 1, 2023 at 14:29 | comment | added | Ángel | While the intent is clear for stack1.pop() <= stack2.pop(), I should note that the order of the pop()s for the same stack is likely unspecified, and could be subject to change with a different compiler/version. | |
| Oct 1, 2023 at 0:26 | history | edited | kaya3 | CC BY-SA 4.0 | added 1 character in body |
| Sep 30, 2023 at 20:57 | history | edited | kaya3 | CC BY-SA 4.0 | added 3 characters in body |
| Sep 30, 2023 at 20:50 | history | answered | kaya3 | CC BY-SA 4.0 |