Re: Add 1 more variable to print
On Apr 20, 8:26 pm, woodbria...@gmail.com wrote:
On Apr 20, 4:12 am, James Kanze <james.ka...@gmail.com> wrote:
On Apr 20, 8:21 am, Juha Nieminen <nos...@thanks.invalid> wrote:
Alf P. Steinbach wrote:
g++ (GCC) 3.4.5 (mingw-vista special r3)
So because a compiler for a system it was not really never
designed for is unable to use dynamically linked libraries
properly in that system, you hate iostreams? Yes, it
makes a lot of sense. iostreams are clearly the culprit
here.
[...]
-- At least where I work, most programs are a little bit bigger
than hello, world. (Say, about a million times bigger, in
terms of number of lines.) The difference in size is
actually an arithmetic constant. So even if I take Sun CC
(where hello, world is 61412 with printf, 501320 with
cout---the worst example I could find), what it really means
isn't that iostream makes the program close to 10 times
larger; what it means is that iostream adds about 450KB to
your program. If I take the main application I'm working
on, it's over 78 MB---a half a meg more or less isn't
important.
I agree with your analysis, but don't go along with the
conclusion. Half a meg is too much. It's difficult to
produce good results if the tools bring along layers of fat
like that.
Half a meg is an extreme case. Only Sun CC is anywhere close to
that. And with Sun CC, the half a meg is less a problem than
the performance problems---the iostream implementation is
really, really bad. The fact that the standard version of the
library is close to 100 times slower than the pre-standard one
is a far greater problem than the fact that it results in a half
a mega more in the size of the executable.
On the same platform, g++ doesn't have these problems. Nor does
the alternative library provided by Sun, the STLport, although
it has other problems.
And of course, this is an extreme case. For
most implementations, the differences are a lot less.
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.
I agree that the standard committee made them worse, that the
pre-standard iostream was considerably better. But what else do
you use? printf and company are probably the worst designed IO
system which has ever existed. And the basic principles which
made the pre-standard iostream so beautiful are still present:
sinking and sourcing remains separate from formating and
parsing, both can easily be customized for user defined types
(or sinks and sources), and you can still use logical markup,
rather than physical. From a user point of view, for serial
text input and output, you can almost ignore all the junk the
committee added. Provided you have a reasonably good
implementation, and not the one provided with Sun CC.
--
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