Re: Why is tellg() returning -1 for IBM, SGI C++ compilers?
Alberto Ganesh Barbati wrote:
kanze ha scritto:
I think the original standard (C98) was unclear here. The
latest current draft, however, clearly says that tellg should
fail: the effects of tellg are "Behaves as an unformatted input
function [...]". An unformatted input function begins by
constructing an object of type sentry, and should fail if this
object returns false when converted to bool. A senty object
returns false if good() is not true for the stream. And good()
will return false if eofbit is set, which it almost certainly
will have been after reading the int.
I somehow missed that. But now that I've read the latest draft I found
that it's not less unclear than the current standard. The sentence that
gives me a headache is 27.6.1.3/40 (about tellg):
"Returns: After constructing a sentry object, if fail() != false,
returns pos_type(-1) to indicate failure. Otherwise, returns
rdbuf()->pubseekoff(0, cur , in )."
Interesting. This doesn't seem totally in agreement with the
immediately preceding paragraph: "Effects: Behaves as an
unformatted input function, except that it does not count the
number of characters extracted and does not affect the value
returned by subsequent calls to gcount()." Part of the behavior
of an unformatted input function (?27.6.1.3/1) is "Otherwise, if
the sentry constructor exits by throwing an exception or if the
sentry object returns false, when converted to a value of type
bool, the function returns without attempting to obtain any
input." ("Without attempting to obtain any input" doesn't
really make sense for tellg(), but presumably, what is meant is
"without trying to do whatever the function is supposed to do".)
There's also the problem that it doesn't seem to say anywhere
what happens in the case where good() is false. The effets
paragraph of the sentry constructor starts with "If is.good() is
true", and never discusses the other case (so presumably does
nothing); all that is sure is that if ! is.good(), conversion to
a bool will return false. Similarly, the text I site concerning
unformatted input functions says what the function doesn't do,
in the case where the sentry object returns false (and thus, if
good() is false); it doesn't say anything about setting failbit,
or whatever.
Most of the other unformatted input functions have something in
their logic which will cause failbit to be set if sentry is
false (sometimes indirectly, e.g. failbit is set if no
characters are extracted, which will certainly be true if we
don't attempt to extract any). Maybe this is really the intent
here, and that tellg isn't meant to set failbit if sentry is
false. And that the text I quote concerning unformatted input
is meant to be taken very literally: if sentry returns false,
tellg should "return without attempting to obtain any input".
(Of course, if sentry returns true, tellg will also "return
without attempting to obtain any input", since its purpose is
not to obtain input.) But then, I wonder why tellg should
construct a sentry object to begin with. About the only effect
of the sentry object is to permit (but not to require, in this
case) a call to is.tie()->flush(). IMHO, a much better
definition of tellg would be:
Effects: none
Returns: fail() ? pos_type(-1) : rdbuf()->pubseekoff(0, cur, in)
It should be a pure function, with no possible side effects.
Suppose fail() != false. Then, according to 27.6.1.1.2/5, the
sentry object (when converted to bool) must have evaluated to
false.
True. The problem is when the sentry object evaluates false,
but fail() is also false, i.e. when eofbit is set, but none of
the others.
27.6.1.3/1 says that "if the sentry object returns
false, when converted to a value of type bool, the function
returns without attempting to obtain any input."
Here are my doubts:
1) as 27.6.1.3/1 says we should return anyway, why 27.6.1.3/40 says that
pos_type(-1) is returned only "if fail() != false"?
Good question. ?27.6.1.3/1 says we should return, but there's
no indication as to what we should return.
2) if eofbit is set, the sentry will evaluate to false, but it might not
set failbit. In fact during preparation the sentry constructor "may call
setstate(failbit)" but it's never said that it should do it and there's
no actual need to do it, because we have noskipws = true in our case.
So, 27.6.1.3/1 says tellg() should return somehow prematurely, but
27.6.1.3/40 does not seems to specify which value we should return!
Exactly.
3) the sentence "the function returns without attempting to obtain
any input" looks really an empty requirement to me, because tellg()
never attempts to obtain any input. So it might be conceivable that
tellg() could simply ignore the result of the sentry evaluation. If this
interpretation is correct, calling pubseekoff() would not only be
allowed, but it would be the required behavior in our case.
Any ideas?
Just that I don't think that the standard is really clear about
this. Logically, what I would like to see (or have seen) is
that sentry set failbit if it would have returned false, rather
than requiring exactly the same logic in all of the functions
(including all of the formatted input functions). And that
functions which don't do input at all not use sentry, because if
the function doesn't do any input, and doesn't skip whitespace
(and none of the functions which don't do input do skip
whitespace), then sentry really doesn't do anything, and the
references to "behaving like an unformatted input function" are
just obfuscation, since the only "behavior" involved is creating
the sentry object (which doesn't do anything), testing it to
determine whether they should attempt input (but they don't
attempt input in any case) and setting the value to be returned
by gcount() (but all of the functions in this case are
documented not to do this).
(It's interesting to note that this *is* the case for output
streams. Where the sentry object really does something, even if
there is no attempt to output characters.)
If the eofbit is set, the sentry object should test false, and
tellg should fail. It doesn't make sense to me, but that's what
the latest draft clearly requires.
I agree, but the problem here is what it is actually meant by "tellg
should fail".
Yes. I'll admit that I stopped reading after the Effects
paragraph, which seemed blatantly clear. The Returns paragraph
is also blatantly clear. It would be nice if they said the same
thing:-).
Independantly of the standard, I think we agree that the logical
thing to do would be for tellg to succeed in this case,
returning a pos_type which corresponded to the end of the file.
--
James Kanze (GABI Software) email:james.kanze@gmail.com
Conseils en informatique orient?e objet/
Beratung in objektorientierter Datenverarbeitung
9 place S?mard, 78210 St.-Cyr-l'?cole, France, +33 (0)1 30 23 00 34
--
[ See http://www.gotw.ca/resources/clcm.htm for info about ]
[ comp.lang.c++.moderated. First time posters: Do this! ]