Re: Add 1 more variable to print
On Apr 20, 9:28 pm, joshuamaur...@gmail.com wrote:
On Apr 20, 11:26 am, woodbria...@gmail.com wrote:
On Apr 20, 4:12 am, James Kanze <james.ka...@gmail.com> wrote:
FWIW: I find a similar ratio in size difference between
std::vector and malloc/free, probably for the same reasons
(templates, C++ library vs. C library). Arguing against
iostream on these grounds is the same as arguing against
vector, rather than malloc/free. (Note that the argument
is iostream vs. printf. I'm sure that it's possible to
design a solution which is better than either of them, but
printf is about the worst IO system ever invented, and
using it instead of iostream is about the same as using
malloc/free instead of vector.)
I disagree with your analogy. I think it makes sense to use
vector rather than malloc/free, but that iostreams were one
step forward and one step backward. At this point I think
it's best to admit that iostreams is dead in the water.
Pardon the pun.
iostreams are one step forward for introducing type safety to
io. Thank iostreams for that.
FWIW: C is, I think, the only language which has ever provided
IO that wasn't type safe. It's (another) major mistake in C.
In that regards, iostreams only bring C++ up to the level of
other languages. Iostreams have other very important
characteristics, which make them in fact superiour to the IO in
just about every other language I know: they cleanly separate
the sinking and sourcing from the formatting and parsing, and
allow customization (e.g. for user defined types or for user
defined sinks and sources) at both levels; they allow user
defined, application specific formatting specifications, without
the physical formatting being embedded in the output statement.
The major problem with iostreams is that people don't know them.
Another minor problem is poor error reporting.
I don't know what your problem with iostreams is, but they're
dead
I don't know why people say they're dead. I've never seen a C++
program that didn't use them.
IMHO a simple reason: the C++ standards committee tried to do
internationalization in the standard libraries, but
internationalization and Unicode support is hard, and they did
it badly. Too much implementation defined (locale names, size
of wchar_t, which locales are present, etc.), no support for
variable width encodings (UTF-8 and UTF-16 included), a
convoluted interface (iostream and strbufs), etc. I much
prefer the Java way of base stream classes, like StringWriter
and FileOutputStream, and stream wrappers, like
OutputStreamWriter. Properly done, it would be about as
efficient as iostreams are now; both involve virtual function
calls.
Actually, it's not that different from iostreams. Although they
did get it right that the code conversion should be a filtering
streambuf. (One could also argue that the same thing holds for
buffering. But performance arguments play a role here---in
Java, if you're reading character by character, you get a
virtual function call per character. In C++, you only get a
virtual call if the buffer is empty; otherwise, the fucntion is
fully inlilned. I don't know whether this makes a difference
today, but it certainly did back when C++ was young.)
--
James Kanze (GABI Software) email:james.kanze@gmail.com
Conseils en informatique orient=E9e objet/
Beratung in objektorientierter Datenverarbeitung
9 place S=E9mard, 78210 St.-Cyr-l'=C9cole, France, +33 (0)1 30 23 00 34