Path: utzoo!utgpu!jarvis.csri.toronto.edu!mailrus!tut.cis.ohio-state.edu!ukma!gatech!ulysses!hector!jss
From: jss@hector.UUCP (Jerry Schwarz)
Newsgroups: comp.lang.c++
Subject: Re: The >> operator
Message-ID: <11258@ulysses.homer.nj.att.com>
Date: 24 Feb 89 21:41:14 GMT
References: <6622@phoenix.Princeton.EDU>
Sender: netnews@ulysses.homer.nj.att.com
Reply-To: jss@hector.UUCP (Jerry Schwarz)
Organization: AT&T Bell Laboratories
Lines: 57

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