0x0 outputs as 0 instead of 0x0

[ciccio]

Hi,

I was puzzled when i noticed that 'zero' in hexadecimal output is
written as '0' and not '0x0'. What is the reason of this?

#include<iostream>

int main(void) {

std::cout.setf(std::ios::hex,std::ios::basefield);
std::cout.setf(std::ios::showbase);

std::cout << 0 << "\t" << 1 << std::endl;

return 0;
}


output gives
0 0x1

Regards

 

[Victor Bazarov]

I was puzzled when i noticed that 'zero' in hexadecimal output is
written as '0' and not '0x0'. What is the reason of this?

#include<iostream>

int main(void) {

std::cout.setf(std::ios::hex,std::ios::basefield);
std::cout.setf(std::ios::showbase);

std::cout << 0 << "\t" << 1 << std::endl;

return 0;
}


output gives
0 0x1

Because the standard says it will do so?

Zero is zero. If you always need "0x" in front of your output you
should drop the 'showbase' and output "0x" yourself.

V

 

[ciccio]

Because the standard says it will do so?

Still why?

 

[Victor Bazarov]

Still why?

Not sure. Probably because that's how C's "printf" behaves.
C++ inherits a lot from C; sometimes the only justification is
that if folks recompile their code with a C++ compiler they
don't get any surprises (at least most of the time). Now, C
doesn't have streams, but there is '#' flag character in the
'printf' formatting specification. The 'showbase' is defined
to mimic it.

If you'd like to know more about justifications that were used
when designing formatted I/O for C++, ask in 'comp.std.c++',
they discuss the rationales behind the decisions to put this or
that in the Standard.

V

 

[Abhishek Padmanabh]

Hi,

I was puzzled when i noticed that 'zero' in hexadecimal output is
written as '0' and not '0x0'. What is the reason of this?

#include<iostream>

int main(void) {

std::cout.setf(std::ios::hex,std::ios::basefield);
std::cout.setf(std::ios::showbase);

std::cout << 0 << "\t" << 1 << std::endl;

return 0;

}

output gives
0 0x1

To keep it consistent, you could use stringstreams and always prefix
0x:

std:stream& printHexToStream(std:stream& os, int input)
std::stringstream ss;
ss << "0x" << std::hex << 26;
os << ss.str();
}

 

[Abhishek Padmanabh]

Correction:

To keep it consistent, you could use stringstreams and always prefix
0x:

std:stream& printHexToStream(std:stream& os, int input)
{
std::stringstream ss;
ss << "0x" << std::hex << input;
os << ss.str();
return os;
}

 

[James Kanze]

Not sure. Probably because that's how C's "printf" behaves.
C++ inherits a lot from C; sometimes the only justification is
that if folks recompile their code with a C++ compiler they
don't get any surprises (at least most of the time). Now, C
doesn't have streams, but there is '#' flag character in the
'printf' formatting specification. The 'showbase' is defined
to mimic it.

That's definitely the reason. All C++ says about showbase is
that if the type is integral and showbase is set, formats "as
if" there were a # in the specifier to printf. (All of the
formatting is specified in terms of printf format specifiers.)
For #, the C standard says: "For x (or X) conversion, a nonzero
result has 0x (or 0X) prefixed to it."

The rationale for the C standard doesn't say anything about this
either.

(It surprised me, too, just a couple of days ago. In the end,
however, I wanted something like "0x1AB", with a small x but
capital hexadecimal digits, so I had to insert the 0x manually
anyway. And since I was using '0' as a fill character at that
point, inserting the 0x didn't require any jumping through
hoops. But I still think it strange.)

If you'd like to know more about justifications that were used
when designing formatted I/O for C++, ask in 'comp.std.c++',
they discuss the rationales behind the decisions to put this
or that in the Standard.

In this case, comp.std.c might be more appropriate. (Of course,
the answer might be simply that that's what all existing
implementations did at the time. And who knows why they did
it.)