Что случилось с setw()?
меня недавно покусал тот факт, что ios_base::width и/или setw манипулятор должен быть сброс с каждым элементом, записанным в поток.
то есть, вы должны сделать это:
while(whatever)
{
mystream << std::setw(2) << myval;
}
вместо этого:
mystream.width(2);
while(whatever)
{
mystream << myval;
}
Ок, хорошо.
но кто-нибудь знает, почему это было сделано? Есть ли какое-то обоснование, которое мне не хватает, или это просто темный угол стандарта?
другое форматирование потока модификаторы (как упоминалось в связанном вопросе SO) являются "липкими", в то время как setw нет.
2 ответов
Как я вижу, это : вы всегда можете сделать что-то вроде ниже, если хотите, чтобы он применялся равномерно.
int width =2;
while(whatever)
{
mystream << std::setw(width) << myval;
}
но если это было Липко, как вы упоминаете:
mystream.width(2);
while(whatever)
{
mystream << myval;
}
и если бы я хотел другую ширину каждой строки, я должен продолжать устанавливать ширину.
следующие моменты кажутся мне особенно важными:
-
some_stream << xнадо просто работать большую часть времени - большинств код который устанавливает ширину немедленно или очень скоро после того как поток значение, поэтому несвязанный код может предположить, что не будет некоторого "ожидающего" значения ширины, влияющего на его выход
-
setfill()не имеет значения если есть доsetw(), поэтому не будет отрицательно влиять наsome_stream << xзаявление возглавляет наш список- только когда ширина явно задана, программист может / должен рассмотреть, является ли состояние символа заполнения подходящим, основываясь на их знании большего вызова контекст
- очень часто для набора значений используется один и тот же символ заполнения
- другие манипуляторы типа
hexиoctявляются постоянными, но их использование обычно в блоке кода, который либо всплывает в предыдущем состоянии, либо (неприятно, но проще) возвращает его в decimal
точка, ведущая от этого, что отвечает ваш вопрос...
- если
setw()были presistent, это должно быть сброс между каждым потоковым оператором для предотвращения нежелательного заполнения...