Stream states questions

[john]

I am reading TC++PL3 and in "21.3.3 Stream State", 4 member functions
returning bool are mentioned:
template <class Ch, class Tr= char_traits<Ch
class basic_ios: public ios_base {
public:
// ...
bool good() const; // next operation might succeed
bool eof() const; // end of input seen
bool fail() const; // next operation will fail
bool bad() const; // stream is corrupted

[...]
};

It is also mentioned:

"If the state is good() the previous input operation succeeded. If the
state is good(), the next input operation might succeed; otherwise, it
will fail.

==Applying an input operation to a stream that is not in the good()
state is a null operation as far as the variable being read into is
concerned."

Q1: What does the above mean?
=="If we try to read into a variable v and the operation fails,"

Q2: Does this mean that fail() becomes true after this?
"the value of v should be unchanged (it is unchanged if v is a variable
of one of the types handled by istream or ostream member functions). The
difference between the states fail() and bad() is subtle. When the state
is fail() but not also bad(), it is assumed that the stream is
uncorrupted and that no characters have been lost. When the state is
bad(), all bets are off".
Q3: When !good() is true, is fail() always true?

[Alf P. Steinbach]

* john:

I am reading TC++PL3 and in "21.3.3 Stream State", 4 member functions
returning bool are mentioned:
template <class Ch, class Tr= char_traits<Ch
class basic_ios: public ios_base {
public:
// ...
bool good() const; // next operation might succeed
bool eof() const; // end of input seen
bool fail() const; // next operation will fail
bool bad() const; // stream is corrupted

[...]
};

It is also mentioned:

"If the state is good() the previous input operation succeeded. If the
state is good(), the next input operation might succeed; otherwise, it
will fail.

==Applying an input operation to a stream that is not in the good()
state is a null operation as far as the variable being read into is
concerned."

Q1: What does the above mean?

It means that in an ungood state, stream input and output operations do
nothing at all (except possibly throwing exceptions, if you have turned
that on).

=="If we try to read into a variable v and the operation fails,"

Q2: Does this mean that fail() becomes true after this?

Yes.

"the value of v should be unchanged (it is unchanged if v is a variable
of one of the types handled by istream or ostream member functions). The
difference between the states fail() and bad() is subtle. When the state
is fail() but not also bad(), it is assumed that the stream is
uncorrupted and that no characters have been lost. When the state is
bad(), all bets are off".
Q3: When !good() is true, is fail() always true?

No.

It helps to consider that fail() checks one bit in a set of possible
problem flags: badbit, eofbit and failbit. good() is not a separate
bit, and it's not the inverted fail bit: good() says that /all/ the
three problem bits are zero. Alles in ordnung.

But note that the only way eof() is set automatically, is by failing to
read beyond end of file, which tends to also set the fail bit.

Also note that operator void* (used for conversion to logical boolean)
and operator! (ditto) just check the failbit.

In other words, let s be a stream object, then if(s){...} is not the
same as if(s.good()){.. .}, it's the same as if(!s.fail()){. ..}. It's
all very perplexing. But, remember, you can just say NO to iostreams.

Cheers, & hth.,

- Alf

[=?ISO-8859-1?Q?Erik_Wikstr=F6m?=]

On 2007-09-08 15:39, john wrote:

I am reading TC++PL3 and in "21.3.3 Stream State", 4 member functions
returning bool are mentioned:
template <class Ch, class Tr= char_traits<Ch
class basic_ios: public ios_base {
public:
// ...
bool good() const; // next operation might succeed
bool eof() const; // end of input seen
bool fail() const; // next operation will fail
bool bad() const; // stream is corrupted

[...]
};

It is also mentioned:

"If the state is good() the previous input operation succeeded. If the
state is good(), the next input operation might succeed; otherwise, it
will fail.

==Applying an input operation to a stream that is not in the good()
state is a null operation as far as the variable being read into is
concerned."

Q1: What does the above mean?

It means that if you try to read from a file into a variable 'value' and
good() == false the data in 'value' will not be changed.

=="If we try to read into a variable v and the operation fails,"

Q2: Does this mean that fail() becomes true after this?

Yes.

"the value of v should be unchanged (it is unchanged if v is a variable
of one of the types handled by istream or ostream member functions). The
difference between the states fail() and bad() is subtle. When the state
is fail() but not also bad(), it is assumed that the stream is
uncorrupted and that no characters have been lost. When the state is
bad(), all bets are off".
Q3: When !good() is true, is fail() always true?

Yes, there are three flags associated with the state of the stream, eof,
fail, and bad. If none of those are set then good() == true.

--
Erik Wikström

[=?ISO-8859-1?Q?Erik_Wikstr=F6m?=]

On 2007-09-08 16:17, Erik Wikström wrote:

On 2007-09-08 15:39, john wrote:

>I am reading TC++PL3 and in "21.3.3 Stream State", 4 member functions
returning bool are mentioned:
template <class Ch, class Tr= char_traits<Ch
class basic_ios: public ios_base {
public:
// ...
bool good() const; // next operation might succeed
bool eof() const; // end of input seen
bool fail() const; // next operation will fail
bool bad() const; // stream is corrupted

[...]
};

It is also mentioned:

"If the state is good() the previous input operation succeeded. If the
state is good(), the next input operation might succeed; otherwise, it
will fail.

==Applying an input operation to a stream that is not in the good()
state is a null operation as far as the variable being read into is
concerned."

Q1: What does the above mean?

It means that if you try to read from a file into a variable 'value' and
good() == false the data in 'value' will not be changed.

>=="If we try to read into a variable v and the operation fails,"

Q2: Does this mean that fail() becomes true after this?

Yes.

>"the value of v should be unchanged (it is unchanged if v is a variable
of one of the types handled by istream or ostream member functions). The
difference between the states fail() and bad() is subtle. When the state
is fail() but not also bad(), it is assumed that the stream is
uncorrupted and that no characters have been lost. When the state is
bad(), all bets are off".
Q3: When !good() is true, is fail() always true?

Yes, there are three flags associated with the state of the stream, eof,
fail, and bad. If none of those are set then good() == true.

Correction, the above sentence should be "No, there are three flags...".

--
Erik Wikström

[john]

Alf P. Steinbach wrote:

>
In other words, let s be a stream object, then if(s){...} is not the
same as if(s.good()){.. .}, it's the same as if(!s.fail()){. ..}. It's
all very perplexing. But, remember, you can just say NO to iostreams.

So, do you suggest going back to the C subset fopen(), etc?

[john]

Alf P. Steinbach wrote:

>

It helps to consider that fail() checks one bit in a set of possible
problem flags: badbit, eofbit and failbit. good() is not a separate
bit, and it's not the inverted fail bit: good() says that /all/ the
three problem bits are zero. Alles in ordnung.

But note that the only way eof() is set automatically, is by failing to
read beyond end of file, which tends to also set the fail bit.

I think that an implementation should understand when the end of file is
encountered. Also I am still learning C++, but doesn't it make sense
that the next read will fail after end of file is encountered?

>
Also note that operator void* (used for conversion to logical boolean)
and operator! (ditto) just check the failbit.

In other words, let s be a stream object, then if(s){...} is not the
same as if(s.good()){.. .}, it's the same as if(!s.fail()){. ..}. It's
all very perplexing. But, remember, you can just say NO to iostreams.

Also, if a stream's bad() is true, doesn't that imply that fail() should
be true in real world?
Also, what about using "if (s.good())" and working with the rest eof(),
fail(), and bad() when the statement becomes false and we want to?

The C subset functions return NULL in case of errors, we can check
"s.good()" alone too.

[Roland Pibinger]

On Sat, 08 Sep 2007 23:33:10 +0300, john <jo**@no.spamwr ote:

>Alf P. Steinbach wrote:

>It's
all very perplexing. But, remember, you can just say NO to iostreams.

So, do you suggest going back to the C subset fopen(), etc?

Have you found one real advantage of iostreams over the 'C subset'?
--
Roland Pibinger
"The best software is simple, elegant, and full of drama" - Grady Booch

[john]

Roland Pibinger wrote:

>
Have you found one real advantage of iostreams over the 'C subset'?

I am still reading TC++PL3, but so far I liked istreams and ostreams.
For example, the simplicity of getting whitespace separated strings:
string s;

do
{
cin>>s;

// ...
}while(cin);
or even this:

char v[4];

cin.width(4);

cin>v;

(it reads 3 characters max and adds 0 in the end).
Isn't this more high level and elegant than the C subset I/O facilities?

[Jerry Coffin]

In article <1189289680.714 224@athprx04>, jo**@no.spam says...

[ ... ]

I am still reading TC++PL3, but so far I liked istreams and ostreams.
For example, the simplicity of getting whitespace separated strings:
string s;

do
{
cin>>s;

scanf("%s", s);

does essentially the same thing, from the viewpoint of the stream. The
one real difference is attributable to the string -- that it resizes
itself as needed to accomodate the data being read.

or even this:

char v[4];

cin.width(4);

cin>v;

scanf("%3s", s);

or:

fgets(buffer, 4, stdin);

Don't get me wrong: I'm not arguing that iostreams lack advantages --
only that the things you've cited don't (directly) show much advantage
for them.

--
Later,
Jerry.

The universe is a figment of its own imagination.

[john]

Jerry Coffin wrote:

>

>string s;

do
{
cin>>s;

scanf("%s", s);

Yes, but this leaves room for overflow, while C++ new I/O facilities
together with the other high level facilities are more elegant, safe and
convenient (as far as I have read until now).

does essentially the same thing, from the viewpoint of the stream. The
one real difference is attributable to the string -- that it resizes
itself as needed to accomodate the data being read.

Yes, which is nice, safe and convenient. If string gets more than it can
accommodate it throws a length_error exception. No way for overflow here.

>

>or even this:

char v[4];

cin.width(4) ;

cin>v;

scanf("%3s", s);

or:

fgets(buffer, 4, stdin);

Don't get me wrong: I'm not arguing that iostreams lack advantages --
only that the things you've cited don't (directly) show much advantage
for them.

Well, the cin way looks more high level and convenient to me.