cout printing ints in hexadecimal instead of decimal

[Diwa]

Our app uses cout to print ints

However on somedays, everything is in hexadecimal format

"ios::hex" or "hex" does not exist in our code anywhere.

Any enviromental variables whivch affect C++ iostreams

Or some library setting "hex"

Or is it the use of C style printfs in the code which confuses c++
iostream?

 

[Pascal J. Bourguignon]

Our app uses cout to print ints

However on somedays, everything is in hexadecimal format

"ios::hex" or "hex" does not exist in our code anywhere.

Any enviromental variables whivch affect C++ iostreams

Or some library setting "hex"

Or is it the use of C style printfs in the code which confuses c++
iostream?

On what days? Would that be on the 16th of each month?

 

[Francesco S. Carta]

Our app uses cout to print ints

However on somedays, everything is in hexadecimal format

"ios::hex" or "hex" does not exist in our code anywhere.

Any enviromental variables whivch affect C++ iostreams

Or some library setting "hex"

Or is it the use of C style printfs in the code which confuses c++
iostream?

As far as I know, the only two things that can (legally) affect the
formatting via any stream are passing a manipulator to them (such as
hex) or explicitly changing their flags.

Neither printf nor any environmental variable should affect such
formatting at all.

My pick is that some call to some external library is directly
affecting cout.

You can check out cout's flags after those calls to find the offending
call (adding a "cout << dec;" after that particular call, to solve the
problem) otherwise you can explicitly put cout in decimal mode every
time before outputting your ints - which should be the correct habit:
never make assumptions on the current state of a shared resource,
either check it or set it to the state you want it to be.

Hope that helps. Feel free to clarify and ask again if I misunderstood
your issue.

Have good time,
Francesco

 

[James Kanze]

This is the most likely cause.

As far as I know, the only two things that can (legally)
affect the formatting via any stream are passing a manipulator
to them (such as hex) or explicitly changing their flags.

The only thing which affects the output of an int are the
different formatting parameters in ios_base: the flags, the fill
character and the width. (For some reason, C++ doesn't use the
precision field, although C does.) These flags can only be
manipulated by member functions. Manipulators call these member
functions.

By convention, inserters (operator<<) which use the width field
should reset it to 0, and change no other formatting parameters
(so fields like precision or the flags are sticky). This is
just a convention, however, and a rogue operator<< can change
things it's not supposed to. (That is, after all, how
manipulators work.)

Neither printf nor any environmental variable should affect
such formatting at all.

My pick is that some call to some external library is directly
affecting cout.

You can check out cout's flags after those calls to find the
offending call (adding a "cout << dec;" after that particular
call, to solve the problem) otherwise you can explicitly put
cout in decimal mode every time before outputting your ints -
which should be the correct habit: never make assumptions on
the current state of a shared resource, either check it or set
it to the state you want it to be.

The "Internet principle" holds: be liberal in what you accept,
and conservative in what you send. Always restore the state
when you're finished, and never count on it being anything
specific.

 

[Diwa]

OP here. Thanks to all who responded.

Here are some facts. This program is multi-threaded (we know iostreams
are not thread safe).

On days when the cout screwup happens, right during program startup,
the logs show that while one thread is in the middle of printing addr
of a memory location using cout (hex by default), another thread
interrupts it with its own cout.

Maybe since the first thread was in the middle of printing addr in hex
format when it got interrupted, the hex flag remained set. Just
guessing.

 

[James Kanze]

OP here. Thanks to all who responded.

Here are some facts. This program is multi-threaded (we know
iostreams are not thread safe).

On days when the cout screwup happens, right during program
startup, the logs show that while one thread is in the middle
of printing addr of a memory location using cout (hex by
default), another thread interrupts it with its own cout.

I know of no implementation which can handle this. You need
some sort of external synchronization for all of your output to
any given instance of an ostream. (You should not need
synchronization for output to different instances.)

Maybe since the first thread was in the middle of printing
addr in hex format when it got interrupted, the hex flag
remained set. Just guessing.

Something like "std::cout << std::hex << someInt" resolves to:
operator<<( std::cout, std::hex ).operator<<( someInt )
There's no way the implementation can prevent a thread switch
between the two calls to operator<<; it's in user code. It's up
to you to ensure that the stream object is properly
synchronized.

 

[Francesco S. Carta]

OP here. Thanks to all who responded.

Here are some facts. This program is multi-threaded (we know iostreams
are not thread safe).

On days when the cout screwup happens, right during program startup,
the logs show that while one thread is in the middle of printing addr
of a memory location using cout (hex by default), another thread
interrupts it with its own cout.

Maybe since the first thread was in the middle of printing addr in hex
format when it got interrupted, the hex flag remained set. Just
guessing.

You can completely walk around this issue by printing your ints to a
stringstream and then dumping its content to cout. Then you can
completely ignore the status of cout and build and keep an invariant
state of your output(s).

Hope that helps, I have no grip on threads, also, I suppose my
suggestion should involve some performance loss.

Have good time,
Francesco