问题
I recently was bitten by the fact that ios_base::width
and/or the setw
manipulator have to be reset with every item written to the stream.
That is, you must do this:
while(whatever)
{
mystream << std::setw(2) << myval;
}
Rather than this:
mystream.width(2);
while(whatever)
{
mystream << myval;
}
Ok, fine.
But does anyone know why this design decision was made? Is there some rationale that I'm missing, or is this just a dark corner of the standard?
Other stream formatting modifiers (as mentioned in the linked SO question) are 'sticky', while setw
is not.
回答1:
The way i see it is : You can always do something like below if you want it to be applied uniformly.
int width =2;
while(whatever)
{
mystream << std::setw(width) << myval;
}
but if it was sticky as you mention:
mystream.width(2);
while(whatever)
{
mystream << myval;
}
and if i wanted a different width every line I have to keep setting width.
So essentially both approaches are almost the same, and i would like or dislike them depending on what i am doing now.
回答2:
The decisions of which manipulators should affect only the next operation seem to be based on logical and empirical observations about what tends to factor common functional needs better, and hence be easier for the programmer to write and get right.
The following points strike me as relevant:
some_stream << x
should just work right most of the time- most code that sets the width will immediately or very shortly afterwards stream the value, so unrelated code can assume there won't be some "pending" width value affecting its output
setfill()
is not relevant unless there's a pendingsetw()
, so won't adversely affect thesome_stream << x
statement topping our list- only when width is being explicitly set, the programmer can/must consider whether the fill character state is appropriate too, based on their knowledge of the larger calling context
- it's very common for a set of values to use the same fill character
- other manipulators like
hex
andoct
are persistent, but their use is typically in a block of code that either pops the prior state or (nasty but easier) sets it back to decimal
The point leading from this that answers your question...
- if
setw()
were presistent, it would need to be reset between each streaming statement to prevent unwanted fill...
来源:https://stackoverflow.com/questions/5905467/whats-the-deal-with-setw