Format of floating point output

[john]

I am reading TC++PL3, and on page 468, at "21.4.3 Floating-Point
Output", it formats floating point output in the style:
cout.setf(ios_b ase::scientific , ios_base::float field); // use scientific
// format

cout<< "scientific:\t" << 1234.56789<< '\n';
However my compiler compiles "cout.setf(ios_ base::scientifi c)" OK.

Does this statement affect more stream states than the original
statement using "ios_base::floa tfield", or is "ios_base::floa tfield"
usage, a redundant explicit statement?

[john]

john wrote:

>

correction:

I am reading TC++PL3, and

==on page 628,

at "21.4.3 Floating-Point
Output", it formats floating point output in the style:
cout.setf(ios_b ase::scientific , ios_base::float field); // use scientific
// format

cout<< "scientific:\t" << 1234.56789<< '\n';
However my compiler compiles "cout.setf(ios_ base::scientifi c)" OK.

Does this statement affect more stream states than the original
statement using "ios_base::floa tfield", or is "ios_base::floa tfield"
usage, a redundant explicit statement?

[James Kanze]

On Sep 25, 12:34 pm, john <[e-mail] ote:

I am reading TC++PL3, and on page 468, at "21.4.3 Floating-Point
Output", it formats floating point output in the style:

cout.setf(ios_b ase::scientific , ios_base::float field); // use scientific
// format

cout<< "scientific:\t" << 1234.56789<< '\n';

However my compiler compiles "cout.setf(ios_ base::scientifi c)" OK.

Does this statement affect more stream states than the
original statement using "ios_base::floa tfield", or is
"ios_base::floa tfield" usage, a redundant explicit statement?

Without the second parameter, it might result in an illegal
value in the floatfield, which would result in undefined
behavior.

Most of the format options are boolean values, represented by
single bits. To set a bit, the implementation simply or's the
bit value with the existing value. For example, if you call
std::cout.setf( std::ios::showp os ), the results will be the
previous value, but with the showpos flag unconditionally set.
For such boolean values, the single argument form of setf is
appropriate, and to reset, you would normally use ios::unsetf.

Three of the format values, however, are non-boolean (i.e. they
have more than two possible values): floatfield, adjustfield and
basefield. Because they have more than two values, they
consist of more than one bit, and simple or'ing won't work.
Consider a case, for example, where the floatfield values are
defined as: unnamed default: 0, fixed: 1, scientific: 2. If the
current value is fixed, and you simply or in scientific, the
results will be 3---an illegal value, which may cause strange
things to happen. For these fields, the two argument form of
setf is used; this form first and's the format with the
complement of the second argument, effectively setting all of
the bits from the second argument to 0, before or'ing the first
argument (which is also and'ed with the second). And the values
floatfield, adjustfield and basefield are defined to contain all
of the bits which need to be reset---with the example values
above, the value would be 3.

Note that this two argument form could be used to reset any of
the one bit flags: call it with 0 as the first argument, and all
of the flags to be reset as the second. This is very
unidiomatic, however, and I wouldn't do it. Basically, in well
written code, the following rules apply:

-- The two argument form is always used to set the base, the
floating point format, and the alignment. The second
argument is always one of ios::floatfield , ios::basefield or
ios::alignfield ; the acceptable values for the first
argument depend on the second argument (and may be 0, cast
to the type fmtflags, although unsetf can also be used in
this case). The two argument form is used to set one field
at a time; although it's quite possible to set more, it's
quite unidiomatic, which renders the code more difficult to
read.

-- The one argument form of setf is used to set any of the
other values, and unsetf is used to reset them. Unlike the
case of the two argument form, it's quite idiomatic to
combine values here, e.g. to call setf with something like
"ios::showp oint | ios::showpos".

-- The "easiest" way to do complicated manipulations on the
flags is to read them, using ios::flags(), manipulate your
local fmtflags variable, then set the flags to the resulting
value (using the non-const std::flags()). This is often
used as well because you want to save the original value,
and restore it when you're through.

I use the third solution in my custom manipulators (which
restore the original flags in their destructor); for some
examples of this, you might want to look at the StateSavingMani p
and *Fmt in IO sub-system of my library
(http://kanze.james.neuf.fr/code-en.html). (Note that most
application code should not manipulate the flags directly, nor
use the standard manipulators, but use rather application
specific manipulators.)

--
James Kanze (GABI Software) email:ja******* **@gmail.com
Conseils en informatique orientée objet/
Beratung in objektorientier ter Datenverarbeitu ng
9 place Sémard, 78210 St.-Cyr-l'École, France, [phone]

[john]

James Kanze wrote:

>
Most of the format options are boolean values, represented by
single bits. To set a bit, the implementation simply or's the
bit value with the existing value. For example, if you call
std::cout.setf( std::ios::showp os ), the results will be the
previous value, but with the showpos flag unconditionally set.
For such boolean values, the single argument form of setf is
appropriate, and to reset, you would normally use ios::unsetf.

Three of the format values, however, are non-boolean (i.e. they
have more than two possible values): floatfield, adjustfield and
basefield. Because they have more than two values, they
consist of more than one bit, and simple or'ing won't work.
Consider a case, for example, where the floatfield values are
defined as: unnamed default: 0, fixed: 1, scientific: 2. If the
current value is fixed, and you simply or in scientific, the
results will be 3---an illegal value, which may cause strange
things to happen. For these fields, the two argument form of
setf is used; this form first and's the format with the
complement of the second argument, effectively setting all of
the bits from the second argument to 0, before or'ing the first
argument (which is also and'ed with the second). And the values
floatfield, adjustfield and basefield are defined to contain all
of the bits which need to be reset---with the example values
above, the value would be 3.

Note that this two argument form could be used to reset any of
the one bit flags: call it with 0 as the first argument, and all
of the flags to be reset as the second. This is very
unidiomatic, however, and I wouldn't do it. Basically, in well
written code, the following rules apply:

-- The two argument form is always used to set the base, the
floating point format, and the alignment. The second
argument is always one of ios::floatfield , ios::basefield or
ios::alignfield ; the acceptable values for the first
argument depend on the second argument (and may be 0, cast
to the type fmtflags, although unsetf can also be used in
this case). The two argument form is used to set one field
at a time; although it's quite possible to set more, it's
quite unidiomatic, which renders the code more difficult to
read.

-- The one argument form of setf is used to set any of the
other values, and unsetf is used to reset them. Unlike the
case of the two argument form, it's quite idiomatic to
combine values here, e.g. to call setf with something like
"ios::showp oint | ios::showpos".

-- The "easiest" way to do complicated manipulations on the
flags is to read them, using ios::flags(), manipulate your
local fmtflags variable, then set the flags to the resulting
value (using the non-const std::flags()). This is often
used as well because you want to save the original value,
and restore it when you're through.

I use the third solution in my custom manipulators (which
restore the original flags in their destructor); for some
examples of this, you might want to look at the StateSavingMani p
and *Fmt in IO sub-system of my library
(http://kanze.james.neuf.fr/code-en.html). (Note that most
application code should not manipulate the flags directly, nor
use the standard manipulators, but use rather application
specific manipulators.)

I suppose you meant "ios_base:: " where you wrote "ios::".

[James Kanze]

On Sep 26, 11:25 am, john <[e-mail] ote:

James Kanze wrote:

[...]

I suppose you meant "ios_base:: " where you wrote "ios::".

Not really. I learned iostreams back with the classical
iostreams, when there was only one base class, ios, rather than
basic_ios<>, deriving from ios_base, and I can never remember
how things got divided up: what went into basic_ios<>, and what
went into ios_base. But it doesn't matter, since everything in
ios_base is also visible in basic_ios<>. So if I'm writing a
template, I'll use basic_ios< charT, traitsT >, but most of the
time, I'll just use ios (or wios), which is a typedef for
basic_ios< char, char_traits< char .

--
James Kanze (GABI Software) email:ja******* **@gmail.com
Conseils en informatique orientée objet/
Beratung in objektorientier ter Datenverarbeitu ng
9 place Sémard, 78210 St.-Cyr-l'École, France, [phone]