Alf said:
* Dietmar Kuehl:
Regarding the first question, there are no alternatives to I/O when I/O
is what one needs; however, the standard streams cover more than I/O.
Sorry if my question was ambiguous. What I meant to ask was what you are
using instead of using IOStreams. ... and even I/O was not precise as I
intended to include formatting and the corresponding parsing.
Regarding the second question, the word "suspect" is a bit personal, and
the word "inherent" makes it a pure rhetorical question for which no
non-rhetorical answer is possible.
In other words, I'm not sure these are honest technical questions.
I don't think "inherent" makes it a pure rhetorical question: your
statement is that IOStreams have bad performance. This, at least to me,
implies that there is something inherently wrong with IOStreams which
makes it impossible to implement them such that they are at least as
efficient as an alternative approach. I happen to disagree with such a
statement and since pure disagreement does not provide a good techical
argument, I have actually implemented the IOStreams (and locales)
library of the standard C++ library. Although I have not optimized all
areas of this implementation, I think it for most uses roughly equivalent
to typical stdio implementations.
But that perception may be due to a recent unfortunate experience with
another poster here, so, responding to the drift of the questions, if not
their literal meanings: although there's probably no inherent limitation
in the standard stream's non-design, in practice it turns out these
streams are extremely inefficient, extremely complicated (to wit, whole
volumes have been written about how to use them for very simple tasks),
and, not the least, they are extremely unsafe, like novice code.
Just to address things:
- I disagree about there not being a design, actually I consider it to
be quite good since independent issues are handled by different
entities: i18n (i.e. location dependent variation in formatting) is
handled by locales, access to "external" destinations by stream buffers,
and formatting by the respective classes. What is wrong with this? The
fact that people refuse to at least look at the design and not to try to
derive from ostream is hardly the fault of the design...
A few rarely used things are not optimal (e.g. the callback mechanism
for resource management of associated data; today this would probably
use a shared pointer or something like this). However, as said, they
are rarely used and rarely necessary.
- I don't argue about typical IOStream *implementations* being indeed
slow. Actually, this is something I complain about to the various
library implementors and I try to help them in improving their
implementation. However, I don't think there is any inherent performance
problem. At least, I'm not aware of any.
- Complicated? Well, yes, complicated things are indeed complicated with
IOStreams like seeking within a file requiring a code conversion.
However, this only applies to the implementation of the underlying
mechanism and not its use. I don't see where IOStream use is
complicated. ... and I don't see where extending the system, e.g. by
implementing new stream buffers for typical needs is complicated. Yes,
a stream buffer involving a code conversion is complicated but it is
readily available as file streams. The fact that there is a book (I
assume you are referring to Angelika's and Klaus' book) doesn't mean
they are complicated themselves, just that you can do lots of things
with them.
- ... and I don't know at all what you are referring to as being "unsafe".
In one discussion about this topic in [no.it.programmering.c++] we
measured performance that was, as I recall, 20 (yes, 20!) or more times
worse than alternatives (for std::stringstream conversion to text).
Unfortunately, I can't read Norwegian and all I could locate was a test
where single letters were combined (the thread is from early this year).
With those test, I could not reproduce a 20 times performance hit, "only"
one of 2. However, the alternatives were the way to go anyway since
concatenation of strings does not really require any form of stream.
Other than this, I'm aware of really bad stringstream implementations
which grow by a constant number of bytes (e.g. the one on the system we
are using grows by 128 bytes) resulting in a quadratic complexity where
it should be linear. Contemporary implementations fix this problem.