another cout format question

[RB]

I've got another iostream format question, since you solved my previous two.
The below small app has a commented out //<< setw(8) that fixes my output padding 0's
on just one problem ptr value, when it is put back in.
My question is, why does the preset cout width and fill work on all the other pointers
but not the last one without adding the setw(8) ?
Also I tried casting it to (int) (UINT) (DWORD) but none of them would help on the
last pointed to pE->pE_Handlr. The setw(8) did fix it though. Just curious why the others
worked without it.
Also a trivial curiosity, I have my Outlook Express news fonts set to monospacB21 but
it does not actually monospace everything? Is there anyway to actually get monospace
in Outlook?

#include <windows.h>
#include <iostream>
#include <iomanip>
using namespace std;

struct E
{
struct E *pNext;
DWORD pE_Handlr;
};

int main()
{
E *pE;
cout.flags ( ios::hex | ios::right | ios::uppercase );
cout.width(8);
cout.fill('0');

__asm // x86
{
push dword ptr FS:[0]
pop dword ptr [pE]
}

cout << " Current Block MemAddr | 1st dword Prev Blk ptr | 2nd dword Handler ptr" << endl;
while (DWORD(pE) != 0xFFFFFFFF )
{
cout << " " << pE << "h " << pE->pNext << "h " << pE->pE_Handlr << "h" << endl;
pE = pE->pNext; // << setw(8)
}
cout << " .---------'\n"
<< " The value of FFFFFFFFh is a marker for the last Block this thread" << endl;
return 0;
}

/*------------- program output WITHOUT the added setw(8) (see above commented out)
Current Block MemAddr | 1st dword Prev Blk ptr | 2nd dword Handler ptr
0012FFB0h 0012FFE0h 42C750h
0012FFE0h FFFFFFFFh 7C839AD8h
.---------'
The value of FFFFFFFFh is a marker for the last Block this thread
------------------------------------------------------------------
program output WITH the added setw(8)
Current Block MemAddr | 1st dword Prev Blk ptr | 2nd dword Handler ptr
0012FFB0h 0012FFE0h 0042CAC0h
0012FFE0h FFFFFFFFh 7C839AD8h
.---------'
The value of FFFFFFFFh is a marker for the last Block this thread
--------------*/

 

[James Kanze]

I've got another iostream format question, since you solved my
previous two. The below small app has a commented out //<<
setw(8) that fixes my output padding 0's on just one problem
ptr value, when it is put back in. My question is, why does
the preset cout width and fill work on all the other pointers
but not the last one without adding the setw(8) ?

I doubt that it works for all but the last. It probably only
works for the first.

There is a general convention for formatted output, adhered to
by all of the << operators in the standard (except the one from
a streambuf*), and which should be adhered to by your operator<<
as well: they reset width to 0 (but change none of the other
formatting parameters).

In consequence, it's a good style point to only set the width
with setw, immediately before the variable it affects, and to
not use manipulators for anything else.

 

[RB]

Thanks for the reply James. You know your stuff on iostreams so I don't
doubt what you say. I do (out of ignorance) wonder "why" they would
reset the cout.width back to zero. I'm sure they must have had a reason
but it does seem inconvenient to the user.

 

[James Kanze]

I do (out of ignorance) wonder "why" they would reset the
cout.width back to zero. I'm sure they must have had a reason
but it does seem inconvenient to the user.

Would you really like it if you wrote something like:
std::cout << std::setw(5) << width << " cm" << std::endl
and got:
25 cm
? For similar reasons, iostreams ignores the precision
specifier for strings, since it isn't reset. In printf,
a precision specifier of a string sets the maximum number of
characters in the string, e.g.:
printf( "%-8.8s\n", someString);
will always print exactly 8 characters. In iostream, this was
deamed less useful than having precision "sticky".

My own feelings are that nothing should be sticky: a formatted
output function should reset everything to its default state.
I've been hit too often by someone who slips in an std::hex for
some debugging output, without resetting it. In my own work,
I use semantically significant application domain manipulators,
which restore the original state at the end of the full
expression. I would argue that this is the only reasonable
solution, except maybe in a case like width. (But in practice,
width doesn't matter much anymore. It's classical use was to
format tables, but now that almost no output uses fixed width
fonts, it doesn't work for that.)

 

[RB]

Would you really like it if you wrote something like:
std::cout << std::setw(5) << width << " cm" << std::endl
and got: 25 cm

I am not understanding what part of the concept you are
referring to, which I suspect is due to my still not complete
understanding of same said concept.
I don't have a problem with the setw(x) going back to
zero afterwards, what I don't understand (or thought you
were origninally referring to) was why cout.width(x) was
setting back to zero? In other words why doesn't
cout.flags ( ios::hex | ios::right | ios::uppercase );
cout.width(8);
cout.fill('0');
this hold for the duration ?