levy@fine.Princeton.EDU (Silvio Levy) (02/24/89)
I've been using g++ for a couple of weeks, it's my first exposure to C++. I'm not very happy with the fact that when something like cin >> i; // i is an int fails (say because the next character is not a digit) the stream's _fail flag gets set, so no input from cin is possible until I reset that flag. This seems to be much more drastic that the corresponding situation in C, where a call to scanf() that returns 0 does not invalidate the input stream. Am I missing something? Is this the best possible design for >> ? Several of my C programs expect to be fed numbers and keywords, variously intermixed, and if the input is malformed an error message is given. It seems that in writing the same programs in C++ I'll have to add a call to clear() every time something unexpected is found in the input. A big pain, in my opinion. Silvio Levy
henry@utzoo.uucp (Henry Spencer) (02/25/89)
In article <6622@phoenix.Princeton.EDU> levy@fine.UUCP (Silvio Levy) writes: >... I'm not very happy with the fact that when something like > >cin >> i; // i is an int > >fails (say because the next character is not a digit) the stream's >_fail flag gets set... Is this the best possible design for >> ? Possibly not. It's not clear that it matters that much, though. If one is being seriously paranoid about input format, i.e. one is expecting input typed by humans, one almost invariably ends up reading in a whole line and then picking it apart in memory. Formatted-input primitives just are not terribly useful when erroneous input is a serious issue; they *never* seem to provide enough hooks for good error handling. -- The Earth is our mother; | Henry Spencer at U of Toronto Zoology our nine months are up. | uunet!attcan!utzoo!henry henry@zoo.toronto.edu
jss@hector.UUCP (Jerry Schwarz) (02/25/89)
In article <6622@phoenix.Princeton.EDU> levy@fine.UUCP (Silvio Levy) writes: >I'm not very happy with the fact that when something like > >cin >> i; // i is an int > >fails (say because the next character is not a digit) the stream's >_fail flag gets set, so no input from cin is possible until I reset >that flag. ... > >Am I missing something? Is this the best possible design for >> ? I believe that this is the correct design decision. There are really two questions here. A) Should ill formed input set an error condition. B) Should the error condition cause future extractions (>>) to fail. The answer to A is certainly yes. There is no alternative for clean handling of error conditions. The return value of the extraction operation is an istream& so that you can do sequences of extractions cin >> i >> x >> k ; The only way for an error to be reported is in some state information. The answer to question B is less clear cut, but on balance it seems to be better to cause extractions to fail until the error condition is cleared. It makes it harder to ignore the error condition (which may be what the original poster is complaining about), and I consider that an advantage. Once an error has occured the whole computation usually becomes nonsense unless the programmer has put in some explicit error handling. What you want is a method that will cause the program to get to the point where status is checked as directly as possible. Usually this just means skipping extractions. Its easier to write code that just does the extractions and depends on them having no effect than it is to check after each extraction. >It seems that in writing the same programs in C++ I'll have to >add a call to clear() every time something unexpected is found in the >input. A big pain, in my opinion. > Once you begin to define classes and with their own extraction operations you discover that the low level extraction operation in these cases are usually best included in some user defined extraction operator istream& operator>>(istream&, X&) ; and the call to clear() together with whatever error recover is appropriate only has to be written once. Jerry Schwarz AT&T Bell Labs, Murray Hill