Re: Why do you deserve a better IO library
Alf P. Steinbach wrote:
* James Dennett:
Alf P. Steinbach wrote:
* psyko:
I'd be glad to hear you opinion.
Yes, the templated iostreams are inefficient, complex, and
whatever bad word exists for a design it applies to them;
they even include two-phase initialization and modal
operation as if the designer searched the darkest most
inaccessible places for bad things to throw in, and,
although that's part of the "complex", they lack separation
of concerns, especially basic binary i/o versus formatting
and parsing.
The separation into streambufs (for basic, unformatted I/O)
and streams (for parsing)?
It might seem as an attempt at separation, yes. But as
mentioned, you cannot implement "cat" for Windows using only
standard C++ functionality. That's because you cannot access
the underlying binary i/o functionality of the standard input
and output streams: you can only access an interface that's on
top of a modal translation engine where the mode cannot be
changed (all three aspects are horrible! and are not things
that occur naturally, they must be intentionally designed in).
But that's something we inherited from C, and that we won't be
able to change as long as our IO is defined in terms of and by
reference to the C standard.
More fundamentally, I don't think it's possible to change the
immutable modality between text and binary streams, and still
support both on many systems. Remember that except for Unix and
Windows, the two modes usually map to two different system file
types -- attempting to open a binary file in text mode, or vice
versa, will fail, and of course, once it's open, it makes no
sense to change the mode. (On the other hand, a lot of
programmers aren't too concerned about portability beyond Unix
and Windows, and offering a function to change the mode, which
is allowed to fail, just like opening a binary file for text is
allowed to fail, would seem to be doable, and would make sense
in my mind.)
To make matters even worse the interface lies to you.
It seems to say "I provide binary, unformatted output", but it
doesn't.
The interface to filebuf doesn't say anything like that:-). Or
rather, is isn't lying when it says that it provides unformatted
output. On the other hand, it does say "I provide direct binary
output", and then slip a locale dependant code translation in on
you. I think the committee sort of messed up on their handling
of that.
I have a great dislike of the naming of many streambuf members,
but they're there for times when we just want a transport layer
without formatting.
Well, my point about that was that it simply /isn't/ there.
You can have one, or the other, but not both (and for standard
input and output, only one, namely translating mode). The
formatting isn't built on top of the binary i/o as it should
be; instead it's interwoven in a spaghetti way that can't be
untangled within the confines of std C++.
I think you're missing the point that the distinction
binary/text is based on a distinction of actual file types in
many systems. This means that there really isn't anyway to
handle it otherwise. Detection of line endings and end of file
is not formatting, it's system level IO.
The transcoding issue is different. How (and if) data should be
transcoded is a very complex issue. In this case, a separate,
intermediate filter class would seem to be the appropriate
solution.
--
James Kanze GABI Software
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! ]