Re: "endl and "\n"
From: Alf P. Steinbach (alfps_at_start.no)
Date: 07/09/04
- Next message: Chad J McQuinn: "Re: why this code has compile error"
- Previous message: John Harrison: "Re: why this code has compile error"
- In reply to: Dietmar Kuehl: "Re: "endl and "\n""
- Messages sorted by: [ date ] [ thread ] [ subject ] [ author ]
Date: Fri, 09 Jul 2004 09:24:32 GMT
* Dietmar Kuehl:
> Alf P. Steinbach wrote:
> > * Dietmar Kuehl:
> > > What alternatives to I/O you are using? ... and where do you suspect
> > > inherent performance limitations for the standard streams?
> >
> > 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.
I'm not. But previously C++ wrappers around the C standard library have
served me well, and for i/o also wrappers around native OS functionality.
Generally C++ lib = unacceptable in all respects, C func = so so but
portable, OS API = fast but non-portable, and these are the main options.
> 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.
Well no, on two counts. "inherent" is something you can point at, but
you cannot point at an emergent property from the, uh, design. And
"impossible" is too strong: I believe it is theoretically possible
to make anything fast, for example, if there are no inherent limits such
as O(2^n) behavior; the question is how hard it is to do that in practice.
> I happen to disagree with such a statement
So do I... ;-)
> 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.
Splicing in comments out of order:
> > 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.
The reason I did not provide a link was that it was "hard" to find. I
have still not found the real meat of the discussion, but I think it
followed this posting, <url: http://tinyurl.com/2z8ap>, where I reported
a factor of 17 times slower for boost::lexical_cast compared to a function
written by Thore Karlsen, using Visual C++. In direct follow-up Tarjei
Knapstad then reported a factor of 15 using gcc, and 33 using Intel.
17, 15 and 33, with typical compilers.
The difference being that boost::lexical_cast uses std::stringstream
while Thore's function used, as I recall, itoa or sprintf or direct
conversion (his website seems to be down so difficult to check).
> 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 think the single most illuminating comment is the one in the standard,
from memory, "if the object is destroyed before it is initialized by
calling the init function the effect is undefined"...
Some of it could perhaps be fixed by choosing better names, e.g. as it is
now 'clear( flag )' _sets_ the specified flag(s) (and clears all others).
But that would just be fiddling with cosmetic issues. For example, how to
make streams work when exception throwing is enabled? Then encountering
end of file when reading from a file will throw an exception...
> - 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.
That is exactly my position, with one little difference: I think the
in-practice is very important.
> - Complicated?
Yes.
> - ... and I don't know at all what you are referring to as being "unsafe".
Random sampling of issues: raw pointers (buffer overflow issues); not
supporting exceptions (see above); encoding failure of single operation as
failure _state_; ignoring (skipping) input; accepting arguments which will
not be treated according to type (e.g. on a wide stream); etc. The "etc."
is mostly ignorance and laziness on my part -- I remember encountering the
issues and concluding, but I won't delve into the dirty details again just
to find examples: when a car has square wheels it doesn't really matter
that there's also much wrong with engine, etc. I avoid the standard
streams except when writing small test programs or recommending ways to do
things for novices (there is a small subset of functionality that is
suitable for novices who need some kind of type-safety in "Hello, there").
-- A: Because it messes up the order in which people normally read text. Q: Why is it such a bad thing? A: Top-posting. Q: What is the most annoying thing on usenet and in e-mail?
- Next message: Chad J McQuinn: "Re: why this code has compile error"
- Previous message: John Harrison: "Re: why this code has compile error"
- In reply to: Dietmar Kuehl: "Re: "endl and "\n""
- Messages sorted by: [ date ] [ thread ] [ subject ] [ author ]
Relevant Pages
|
