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:
On Mon, Jan 05, 2004 at 03:37:26PM -0700, Martin Sebor wrote:
Nathan Myers wrote:
initialization is supposed to be the
responsibility of the owner of the object, e.g. whoever created
it.
Yes, I agree with this policy in general. In the case of functions
whose performance is critical, though, it may, IMHO, be quite
appropriate to violate it by allowing callers to pass uninitialized
iostate by requiring the get() members to always set its value. Not
only could it save a CPU cycle or two, but it would also make the
get functions more robust in the presence of user errors. Unless
you or someone else objects to a change to the text that would
codify this policy I will write up an issue and propose that all
facets, not just num_get, behave this way.
That would break existing user-written facets that abide by the
letter of the standard.
Which one? ;-) I'm not too concerned about any breakage since
the existing requirements are already inconsistent among the
facets:
num_get: set iostate = goodbit/eofbit on success,
set iostate = eofbit/failbit on error
money_get: leave iostate alone on success,
set iostate |= eofbit/failbit on error
time_get: leave iostate alone on success,
set iostate = failbit on parse error
Anyway, requiring the facet to initialize
reduces performance (if minimally). A good caller initializes his
variable anyway, so for the facet to initialize again is redundant.
True. There would be a tradeoff in some cases. Currently, num_get,
arguably the most performance sensitive of the facets, (re)assigns
goodbit on success, even if the caller has already initialized err
to goodbit. So the change I propose would not affect num_get in the
common case (success). It might, however, affect both money_get and
time_get callers if they set err to some non-zero value and expect
the same value in err on successful return from the function. I do
not expect there to be much code that exploits such dubious behavior,
though.
The treatment of the "err" argument was meant to match that of the
C library's "errno" global -- nothing touches it unless there's an
error. I'd rather see an issue entered to say that num_get<>::get
never touches it except to assign failbit.
Okay then. Assign by operator|=() or by operator=()?
[...later...]
Okay, I see your response to Carlo. So what you're proposing is
to change num_get not to assign goodbit on success. A change would
also be needed to allow time_get to set eofbit since 22.2, p2 does
not mention it. The mention of "parsing" should also be stricken
from 22.2, p2, since other types of errors might occur and should
be reported. Agreed? Anything else?
Martin