3 ms·
int a; cin >> a; Then the program goes berserk as soon as the first non-number is read out of standard input. All the other "cin >> integer" lines are immedi
by Dwedit 2y ago
int a;
cin >> a;
Then the program goes berserk as soon as the first non-number is read out of standard input. All the other "cin >> integer" lines are immediately skipped.
Yes, I know about error checking, clearing error condition, discarding characters. But it's a whole lot of stuff you need to do after every single "cin>>" line. It makes the simplicity of cin not worth it.
- tightbookkeeper 2y agoYou’re holding it wrong. Like nan, the point is you don’t have to error check every operation. You check error for the whole batch.
- eMSF 2y agoHow could you ever continue after the second statement without checking if you actually read an integer or not? How would you know what you can do with a?
- jvanderbot 2y agoYou couldn't or wouldn't. but why have a read statement like cin>> which looks so nice and clean when you then have to go and check everything with flags and boolean casts on stateful objects. I agree. It's lunacy. just be explicit and use functions or equivalent like literally every other language.
- chongli 2y agoWell in a language like Haskell you could solve this with monads and do-notation. The general idiom in Haskell is to use a Maybe or Either monad to capture success/failure and you assume you’re on the happy path. Then you put the error handling at the consumer end of the pipeline when you unwrap the Maybe or Either. I believe Rust has adopted similar idioms. I’ve heard the overall idea referred to as Railway-oriented programming. In C++ you could implement it with exceptions, though they bring in a bunch of their own baggage that you don’t have to deal with when using monads.
- PaulDavisThe1st 2y agofscanf (STDIN, "%d", &a); the program goes beserk as soon as the first non-number is read out of standard input. in both cases, you need error checking (which you "know about").
- unwind 2y agoNo actual C programmer who has been around the block more than halfway should do that. The mantra is: "read into a character buffer, then parse that". It's more code, sure, but it buys you a lot of good things. I/O is hard.
- PaulDavisThe1st 2y agoNo C++ programmer who has been around the block more than halfway should do cin >> a; and assume that it works. But also ... sscanf (the_buffer, "%d", &a); doesn't help the problem in any substantive way.