Re: String with integers?
On Apr 1, 8:00 pm, Jorgen Grahn <grahn+n...@snipabacken.se> wrote:
On Wed, 01 Apr 2009 10:24:28 +0200, Alf P. Steinbach <al...@start.no> wro=
te:
* James Kanze:
...
(The basic problem, of course, is that there are many valid
conversions of an int to a string. In anything but toy
programs, you generally have to specify some of the
details.)
...
Whether the program is toy or the next Photoshop has nothing
to do with it; in both kinds of program the default simple
conversion is the one most often required, and the
zillions-of-options one the one least often required.
I find that with integers, I usually have to specify the
width, for alignment in tables. Often hex too, although I
guess most other applications do not print a lot of hex. With
float and double, I think you almost *always* want to specify
the precision, so you do not mislead your users by printing
lots of digits which are deep within the numerical error.
Alf's actually at least partially right with regards to
integers. There is a more or less reasonable default, which is
sufficient for debugging and trace outputs, at least. This
doesn't extend to other types, however, and even with integers,
you'll often want something other than the default.
The nice thing about C++ is that we can choose, and many
choose to not use iostreams except for -- heh, toy
programs. ;-)
What else is there to choose from? <cstdio> is a design
disaster. The original iostream was actually pretty good, and
could even serve as a model solution for some design problems.
(Note the different techniques used to allow extension, e.g. to
support user defined types, or to support user defined sinks and
sources.) I don't think there's any way the changes made by the
standards committee can be considered an improvement, but at
least, you can ignore them most of the time.
With other peoples' classes, you have no choice. If they can
be printed at all, it's by placing them on an ostream. There
is no other universally accepted way.
Well, boost::format (or my older GB_Format) could handle them.
In both cases, of course, because they're just wrappers around
ostream.
--
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