PSPS: (a Pre-scripted Post-script)
It has just come to mind that a more prescient question would have included the notion of: Is this non-display of "0x"(showbase) for zero-value integers a standard behaviour, or is it just a quirk of my MinGW implementation?
It all began on a pleasant Sunday morning... I want to dump some Handles in their hex representation, and in a consistant, formatted way.
I want a leading 0x and a fixed width, but this is proving to be elusive using the expected stream manipulators.
The only way I've found to do this is to cast the Handles to an unsigned long.
This seems a bit unreasonable, and I would expect that I'm not the only person to have ever wanted this..
Am I missing something in the standard hex manipulators? Is it because type void* (HANDLE) is simply defined outside of the normal hex-handling of ostream?
In summary: I don't want to have to cast HANDLE to something which it isn't.
and I don't want to hard code a "0x" prefix. Is there a way to do it using standard manipulators? or would I need to overload ostream's handling of HANDLE? (but that might overload me!)
Here is my test code (and its output).
I've used '.' as the fill char, for clarity, (I will actually be using '0')
HANDLE h;
ULONG ul;
int iH = sizeof(h); // how many bytes to this void* type.
int iW = iH*2; // the max number of hex digits (width).
int iW2= iW+2; // the max number of hex digits (+ 2 for showbase "0x").
int iX = 4; // the number of bits per hex digit.
int ib = iH*8; // the max number bits in HANDLE (exponent).
int i;
std::cout<<std::setfill('.'); // I actually want '0';
// the dot is for display clarity
for( i=0; i<=ib; i+=iX )
{ ul = (pow(2,i)-1);
h = (HANDLE)ul;
std::cout
<<"// ul " <<std::setw(iW2)<<std::hex <<std::showbase <<std::internal <<ul
<<" h " <<std::setw(iW2) /* hex,showbase,internal have no effect */ <<h
<<" I want 0x"<<std::setw(iW) <<std::hex <<std::noshowbase<<std::right <<(ULONG)h
<<std::endl;
}
// ul .........0 h .........0 I want 0x.......0
// ul 0x.......f h .......0xf I want 0x.......f
// ul 0x......ff h ......0xff I want 0x......ff
// ul 0x.....fff h .....0xfff I want 0x.....fff
// ul 0x....ffff h ....0xffff I want 0x....ffff
// ul 0x...fffff h ...0xfffff I want 0x...fffff
// ul 0x..ffffff h ..0xffffff I want 0x..ffffff
// ul 0x.fffffff h .0xfffffff I want 0x.fffffff
// ul 0xffffffff h 0xffffffff I want 0xffffffff
I found this on https://bugzilla.redhat.com/show_bug.cgi?id=166735 - this is copy/paste straight from there.
Doesn't sound like a bug to me. ISO C++98, 22.2.2.2.2/10 says std::showbase means prepending # printf conversion qualifier. 22.2.2.2.2/7 says std::hex means the printf conversion specifier is %x. So the behaviour is IMHO required to be the same as printf ("%#x", 0); But http://www.opengroup.org/onlinepubs/009695399/functions/fprintf.html says: "For x or X conversion specifiers, a non-zero result shall have 0x (or 0X) prefixed to it." The same is in ISO C99, 7.19.6.1(6): "For x (or X) conversion, a nonzero result has 0x (or 0X) prefixed to it."
So it sounds like the C++98 standard (by saying 'make it like C's printf("%#x", 0)') requires this goofy behavior you're seeing. The only way to get what you want would be to get rid of the std::showbase and output 0x explicitly. Sorry.