|
you got chatgpt or something to write all that right? If you sat down and wrote that yourself for the sake of making a joke in the computer programming thread then either you're crazy or i am.
|
#
¿
Mar 13, 2024 02:07
|
|
|
|
| # ¿ Apr 27, 2024 12:48 |
|
|
Breetai posted:(e.g. it's a historical data store) you mean i.e. not e.g.
|
|
#
¿
Apr 2, 2024 20:11
|
|
|
Soricidus posted:The problem with it is that having a case statement in the middle of a loop is the kind of thing that might plausibly be undefined behavior or a compiler-specific extension. It’s obvious what the code intends to do, but it’s not a common idiom, so unless you’re familiar with the trick, it’s not obvious whether it will actually do that reliably, even if you run it and it seems to work on your machine. I was going to say that it should be ok because no initialization of variables was being skipped, but actually it potentially is if I understand correctly. The initialization of i to 0 occurs in the for loop header and it ought to run because the state is initialized to "at start" - but having said that, all the properties are public, so the user could construct one of these, then change the state and then call resume() to get it to run without i being initialized? But you could fix that by just initializing i to 0 along with all the other members so I don't know why the author didn't just do that. Even if the enum member was (say) made private so that you couldn't do that, it seems like it's asking a lot of the compiler to prove that i isn't accessed before it's initialized? You would think the compiler would warn about it. I guess in C++ both the "switch" and "for loop" language features translate pretty directly to labels and gotos, and it's clear how you convert that code into labels and gotos and it shouldn't cause any problems, so other than the uninitialized variable thing, I don't know how plausible it really is that it would be undefined. It's a while since I touched C++.
|
|
#
¿
Apr 10, 2024 20:14
|
|
|
RPATDO_LAMD posted:"this is bad because if you gently caress with internal object state you can put it in an invalid state" is a very "you're holding it wrong" kind of problem to have It's not internal object state though, it's public. The language gives you the tools to make it internal, but the author of this code neglected to do that. It's not like Python where everything is based on conventions and promises. If something is left public in C++ then the user is entitled to suppose that that means you intended for them to be able to modify it.
|
|
#
¿
Apr 10, 2024 22:31
|
|