Re: Make std::cout accept std::wstring ?
On Sun, 11 May 2014 05:44:01 -0700 (PDT)
Seungbeom Kim <musiphil@bawi.org> wrote:
On 2014-05-09 06:11, James K. Lowden wrote:
On Thu, 8 May 2014 06:39:57 CST
Seungbeom Kim <musiphil@bawi.org> wrote:
Can you please explain what is the EOF ambiguity of read(2)?
When read(2) returns zero bytes, it may mean that no data
were pending on a socket with nonblocking I/O, or EOF.
I thought I'd get an error of EWOULDBLOCK if no data were pending
on a nonblocking socket.
Quite right. I was thinking of fread(), which when it returns zero has
to be checked with feof() and ferror(). I remembered there was
ambiguity, but not the condition. :-/
If you disassociate a stream from files and sockets, though -- if
it's "just a stream" -- then we *can* imagine bad independent of
fail. If the stream can reflect the physical removal of the
datasource -- say, an Ethernet plug or USB connection -- it could
report "bad" in lieu of a read operation. We can also imagine EOF
being signified as part of the communcations protocol, not
requiring a short read to be discovered. Why not?
Are you saying that an error from the physical source sets badbit, and
an error purely within the stream layer (e.g. conversion to an integer
from characters that have been read from the source successfully) sets
failbit?
Not *does*, but could. The design and semantics of the iostream status
word perforce antedate implementation and standardization.
I'm not making any statement about the standard; I'm just defending the
design. There's a difference between "the last operation failed" (e.g.
could not convert) and "the stream is no longer usable" (e.g. the
device has been disconnected).
As currently implemented, afaik there's no way badbit will change state
without a failed operation, so bad implies fail. You would be rightly
suprised to find failbit behaving as volatile, spontaneously changing
to reflect the device state. I'm only saying that's an artifact of
the current implementation, not the design per se.
* badbit indicates a loss of integrity in an input or output sequence
(such as an irrecoverable read error from a file);
* failbit indicates that an input operation failed to read the
expected characters, or that an output operation failed to generate
the desired characters.
Right, in the first case the stream is kaput, pushing up daisies, an
ex-stream. Nothing you do, even putting the floppy disk back in the
drive, will bring it back.
In the second case, you stil have a chance. The tellg() pointer hasn't
budged, and you can re-try the input with a different conversion.
Arguably, it's confusing because the first is a property of the stream
and the second is a property of the operation. Traditionally functions
return status -- erc = func(...) -- but the iostream operator syntax
precludes that, so the status is stashed in the stream. The
property of the stream becomes, "the last operation failed".
enum of three enumerators (e.g. { good, fail, bad }) could have
been much clearer (assuming that eofbit is independent of the
others).
and of course that's what we have, in the form of good(), bad(),
fail() and eof(). Is it so important that it be an enumerated
type? Would that actually simplify anything?
Again, the difference is in the number of (seemingly) possible states.
For example, given a simple traffic signal with red, yellow, and
green lights where one and only one of them is ON at any given time,
'enum { red, yellow, green } state();' is a better interface than
'bool red(), yellow(), green();' because with the former you know
exactly which one of the three states you are in, and you don't
need to worry 'What if red() and yellow() are both ON?'.
Agreed. I think the question boils down to whether or not failbit and
badbit represent orthogonal states.
We know operations can fail without the stream "losing integrity". We
can imagine the stream going bad spontaneously (if, say, the operator
unmounts the drive) even if current implementation requires a failed
operation to report it. ISTM the two states are quite independent.
--jkl
--
[ See http://www.gotw.ca/resources/clcm.htm for info about ]
[ comp.lang.c++.moderated. First time posters: Do this! ]