Re: Why do you deserve a better IO library
Yes, the templated iostreams are inefficient, complex, and whatever bad
word exists for a design it applies to them;
So, on this point we agree. (except that you're going a bit far with
'whatever word exists for a bad design it applies', IOStream is bad but
The worst two symptoms of the totally failed design is that you cannot
write "cat" in standard C++ for Windows,
Why? What's the problem with:
int main(int, char**)
X:\> cl /nologo /GX /GR cat.cpp
X:\> cat <cat.cpp
X:\> cat <cat.exe >poi.exe
X:\> dir | find ".exe"
10.06.2006 02:04 73 728 cat.exe
10.06.2006 02:04 4 378 poi.exe
The problem here is that C++ allows a translation of the data, which
translation logically belongs to a much higher formatting layer or
alternatively outside the program. Newline markers are translated, and
ASCII value 26 (control Z) is interpreted as end-of-stream. And that
makes the functionality unusable.
the standard iostreams have Undefined Behavior for input
(due to definition in terms of scanf-family),
Oops, still don't get it! could you explain?
As I wrote, because of the definition in terms of the scanf-family,
which for some cases has undefined behavior when input is not as
expected; that C library UB then bubbles up into the C++ library.
plus the complexity means they're great to
write books about, and (apart from boost::lexical_cast) that's what
they're used for.
Are you joking here? :)
Yes, but as Piet Hein remarked,
"Den som kun tar sp?k for sp?k og alvor kun alvorligt, han og hun har
faktisk fattet begge dele d?rligt."
In English translation by Babelfish, uh, wait, it doesn't have
Norwegian, using InterTran instead (hopefully not written in C++?),
"Whoever barely grasping sp??k for sp??k and earnestness barely
earnest , he and she has actual comprehend both d??rligt."
Instead of new iostreams I'd like to see support added for defining
one's own alternatives.
a standardized way to associate basic types (including
possibly typedef'ed types such as size_t) with data necessary for i/o,
Do you mean changes in the language? can you elaborate?
Language or library support, or both.
Although I'm not a fan of iostreams, I think implementing them provides
a good test case for whether the language & library is /complete/.
Regarding associations, think about portably writing a template function
template< typename T >
With one C++ compiler std::size_t may be typedef unsigned long size_t,
with another it might be that std::size_t isn't any of the built in types.
There is at least one portable solution, assuming that it's not
necessary to identify e.g. size_t as being size_t (i.e. that only the
characteristics are important), but it's ugly and possibly inefficient.
Regarding initialization, std::cout is ready-to-use at any time, even in
a constructor of a global object; you can not achieve that for your own
object. That functionality ties in with e.g. logger singletons. And
with the whole problem area of well-defined initialization order (or
rather, the lack of that) across translation units.
A: Because it messes up the order in which people normally read text.
Q: Why is it such a bad thing?
Q: What is the most annoying thing on usenet and in e-mail?
[ See http://www.gotw.ca/resources/clcm.htm for info about ]
[ comp.lang.c++.moderated. First time posters: Do this! ]