Re: Why do you deserve a better IO library
Alf P. Steinbach wrote:
* psyko:
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 the 'whatever word exists for a bad design it
applies', IOStream is bad but not evil).
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:
#include <iostream>
int main(int, char**)
{
std::cout<< std::cin.rdbuf();
}
X:\> cl /nologo /GX /GR cat.cpp
cat.cpp
X:\> cat <cat.cpp
#include <iostream>
#include <ostream>
int main()
{
std::cout<< std::cin.rdbuf();
}
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
X:\> _
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 problem here is that one of the goals of C++ is that it can
be implemented on a wide variety of systems. And there are only
a very few systems in which a Unix like cat program is even
possible: although those few (Unix and Windows, in particular)
are fairly widespread, they are hardly representative, or
typical.
(Another part of the problem is that Windows compilers cater to
a certain degree of backwards compatibility. And under CP/M,
you needed that EOF character, because files could not have an
arbirary length.)
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.
Just curious, but do you know of an implementation that does
something wrong here. (I agree that it's lamentable that the
standard doesn't require the right thing. But from a practical
point of view, I've not found it to be a real problem, because
actual implementations are more responsible.)
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."
Which I don't understand any better than the original
Norwegian:-). Machine translation still has a way to go.
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 >
std::string printfSpecifier();
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.
In standard C++, it's required to be one of the four basic,
unsigned integral types. At present -- this will doubtlessly
change with the next revision of the standard, to bring C++ in
line with the C standard. But the requirement will still be
that it be an unsigned built in type, although it might not be
one of the five (unsigned long long has been added) basic
unsigned integral types.
I'm not sure what problem you are referring to here: in C90 (and
the C library parts of C++), the correct printf specifier for
size_t is one of "%lx", "%lo" or "%lu" -- and you cast the value
to unsigned long before passing it to printf.
In C99, of course, it's "%zx", etc.
All of which points out weaknesses of the printf formatting
paradigm. Weaknesses which aren't present in iostreams.
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.
Using printf-like formatting is ugly. And possibly inefficient
-- the more complex the type system, the harder it has to work.
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.
Sure you can. Or at least, you can give the same guarantees
that cout gives (which are less than many people think). How do
you think the library authors implement cout?
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.
That's another issue. And a real problem at times. You can, in
fact, count on zero initialization having taken place before any
other initialization, and it's also possible to exploit this so
that an object can be used before its constructor has been
called, and that calling the constructor on it once it has been
used doesn't undo any effects that occurred previously. Doing
so definitly falls in the category of "tricky programming",
however, and should be avoided if at all possible.
--
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! ]