Когда я сталкивался с этим в прошлом, я использовал stringstream
вместе с манипулятором, который отображает текущее содержимое stringstream
, используя MessageBox
:
#include <windows.h>
#include <sstream>
#include <ostream>
std::ostream &MessageBox(std::ostream &s) {
std::ostringstream *st = dynamic_cast<std::ostringstream *>(&s);
if (NULL != st)
::MessageBox(NULL, st->str().c_str(), "", MB_OK);
return s;
}
Чтобы использовать это, синтаксис выглядит довольно похоже на использование cout
, но с MessageBox
заменой std::endl
. Например:
std::ostringstream stm;
stm << " blah blah blah. Value: " << 1213.1231 << MessageBox;
Редактировать: в основном для fnieto. В этом случае, унылый необходим . Причина довольно проста: типичный инсертор получает и возвращает ссылку на ostream:
std::ostream &operator<<(std::ostream &os, T const &t) {
// code here to insert t into os, then return os;
}
Это берет оригинальный объект stringstream и молча (и безопасно) приводит его к простому ostream. Это само по себе прекрасно и прекрасно работает для большинства устройств вставки и манипуляторов, потому что они взаимодействуют только с самим интерфейсом ostream
.
Этот манипулятор, однако, немного отличается - он использует элемент str()
, который ostream
не определяет вообще. Для нашего вызова str()
для разрешения и компиляции мы должны преобразовать ostream &
в ostringstream &
, чтобы компилятор знал, что объект, с которым мы работаем, действительно будет иметь член str()
.
Чтобы исключить снижение, у нас действительно был бы только один выбор: сделать его параметр ostringstream &
. Это будет работать до тех пор, пока мы никогда не зацепим операторов:
my_stream << x;
my_stream << MessageBox;
но попытка связать их не удастся:
// should be equivalent:
my_stream << x << MessageBox;
Хуже того, сообщение об ошибке компилятора, вероятно, попытается сообщить пользователю что-то о std::basic_ostream<char>::str()
, которое вообще не упоминается в коде пользователя. Хуже того, большинство людей достаточно привыкли к цепочкам или не дают одинаковых результатов, так что им, вероятно, понадобится некоторое время, чтобы даже понять, почему код иногда работал нормально, а в других случаях не компилировался с совершенно неразборчивым сообщением об ошибке.