This is the mail archive of the
libstdc++@gcc.gnu.org
mailing list for the libstdc++ project.
Re: [RFC] err |= ios_base::failbit or err = ios_base::failbit?!?
Nathan Myers wrote:
...
There is no text specifying what time_get does with the iostate
argument, so it presumably defaults to 22.2, p2, creating an
inconsistency between how the facets report errors to callers.
A caller who passes a local variable initialized to ios_base::goodbit
will not notice any inconsistency. However, both are specified to
ignore the incoming state of the argument, so it's not strictly
inconsistent. It's just that the num_get<>::do_get members are a
bit overactive -- or overspecified.
The problem is that the caller may have set the state to some
value other than goodbit and expect to see that bit still set
after a failed extraction. That will be the case with num_get
and money_get, but not time_get. Another problem is that the
caller might leave the iostate variable uninitialized, and
expect the get() member function to set it regardless of
whether it succeeds or not. That seems to be the case with
num_get but not the other facets.
22.2p2, though, does reinforce that use of operator|= is not permitted.
Yes. I'm not sure whether one is a lot better than the other but
my preference would be to have all the extractors consistently set
or clear all the bits of the iostate argument in any case, if only
to eliminate user errors caused by uninitialized variables.
We should check that the istream extractor code does
the Right Thing with error results from facet calls, and does not
(e.g.) just pass the basic_ios member directly as the err argument.
You're probably thinking of passing *this as the ios_base asrgument
(there is no conversion from ios_base to iostate).
No. The extractors take an (inherited) basic_ios<> argument, which
(presumably) has a member of type ios_base::iostate. I was saying
that such a member (if any) should not be passed directly, but rather
they should pass a properly initialized local variable.
Gotcha! Yes, I would certainly agree with that :) (It didn't occur
to me that the extractor, being a member of basic_istream, might
even have access to the data member of its base class, and not call
iostate() as non-member extractors would have to.)
Martin