Re: formatted output question with strings
On Jul 23, 12:45 pm, Juha Nieminen <nos...@thanks.invalid> wrote:
Jojo wrote:
I'll look that up. At first glance, the C++ method seems much less
'comprehensive' than sprintf. But I think it's better for me to get rid
of my plain-C habits when coding C++ :-)
The C-style format string functions are compact, relatively easy
to learn and remember, and fast.
They're compact. That's all you can say for them. They're
very, very limited in what they can do, however, and they're
very, very low level, and don't support higher level
abstractions. They also quite exoteric; even after 25 years of
using them, and actually having written an implementation of
printf, I still have to check with the manual for anything but
the simplest formatting.
Once you get the hang of them, it's
very easy to perform relatively complex formatting with a very small
amount of code which only takes a small amount of time to write.
And it's impossible to write any maintainable code, because the
low level formatting details creep down into the high level
output statements.
Also, you never need to worry if some formatting setting "leaks" or
not (ie. if the stream will "remember" that setting or forget about
it immediately after printing the value).
The C++-style printing functions are much more verbose, and a
complex C one-liner can easily become over a dozen of lines of C++
(or, alternatively, a dozen of << operator calls in a row) using
diverse function names from <iostream> and <iomanip>.
Not if you use it correctly. (Anything can be abused, of
course.) The difference is that in the C output, you have to
provide all of the information for physical formatting in the
single statement. In C++, you provide the information for the
physical formatting in the manipulator (which works more or less
like a style sheet in a word processor); the client code just
invokes the correct logical manipulator. And most of the time,
even that isn't necessary, because all of the logical
information for formatting is implicit in the type of the
expression. So you end up with:
std::cout << myVariable ;
instead of:
printf( "%-30s %5.2f %3d",
myVariable.getName(),
myVariable.getValue1(),
myVariable.getValue2() ) ;
(What was that about printf being compact?) And of course, the
C++ version continues to work correctly when value2 is changed
from int to long, or when an additional value is added, or when
it is suddenly decided that value one need three digits after
the decimal.
In some cases it also feels a bit inconsistent whether some
stream setting is remembered or forgotten between << operator
calls. Most are forgotten, but some are remembered, causing
potential "formatting leaks".
That's probably the one real pain of iostream formatting. All
of the formatting flags except width are "sticky". So you throw
in a quick additional output for debugging purposes:
std::cout << std::hex << value << std::endl ;
and all of the output which follows is in hex. (It's a
"feature" when outputting tabular data, of course: set the
precision once, before iterating over the table. But
generally...)
My own manipulators restore the original formatting flags in
their destructor, i.e. at the end of the full expression. And
of course, I've got an RAII class for restoring the original
format as well, which can be used in a function which modifies
formatting. But I agree that such things really shouldn't be
necessary.
--
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