Re: Why do you deserve a better IO library
Ivan Vecerina wrote:
"James Dennett" <jdennett@acm.org> wrote in message
news:kkWhg.102786$iU2.96680@fed1read01...
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)?
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.
But in fact, the streambuf (sub-)classes are IMO *unusable*
when binary i/o is needed:
I use them, but I'll admit that the basic streaming idiom seems
to suggest text IO to me. (In fact, almost every time I've
needed binary IO, I've needed functionality such as
synchronization, which isn't available at the filebuf
interface.)
- Absence of type discrimination between input-only,
output-only, and i/o instances.
I've not found that to be a big problem. You just use the side
you want. (The semantics of synchronization between input and
output are vague enough that I don't generally use them for
bidirectional IO.)
- Absence of type discrimination between stream-only or
random access storage. (in practice, I find 90% of my i/o
code is stream-only, when I access random-access disk
storage I usually prefer other techniques, such as
memory-mapping).
Agreed. The basic abstraction is streaming; the random access
stuff seems like something that was added on as an after
thought.
- What do locales (streambuf::getloc/pubimbue) have
to do with binary i/o ?
I've yet to figure that one out either. (The IO streams that I
learned didn't have any locale support in the streambuf layer.)
- Inconsistent error handling: depending on the instance or
subclass being worked with, errors may be reported using
exceptions or using an eof return value. It is difficult
and expensive to write code that is correct in both cases.
I would much prefer to have distinct throwing and
non-throwing functions in the interface.
I'd settle for some well established conventions. At present,
there really isn't any means of declaring an error on input; at
least, nothing that can be reliably distinguished from an end of
file. And on output, there is no formal distinction between
trying to write a character which cannot be transcoded, and disk
full.
I think that the intention is that any hardware level errors
throw an exception. But for various historical reasons, this is
far from being a universal convention.
- Cryptic function names, complexity.
The function names are bizarre, but I've not noticed that much
complexity.
- Usually poor performance in most of the available
implementations.
Curiously, I've not found that to be the case either. Any
performance problems I've found in iostream have been at the
istream and the ostream level.
As a result, if I am ever forced to use a streambuf instance
for binary i/o, I will definitely want to wrap it behind a
'facade' class with a cleaner interface.
And force your readers to learn yet another interface, when the
interface that they already know is already present?
--
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! ]