Макрос формата C ++ / встроенный ostringstream

Вы все уже в значительной степени справились с этим. Но уследить за этим немного сложно. Так что позвольте мне резюмировать то, что вы сказали ...

Вот эти трудности:

• Мы играем с временным ostringstream объектом, поэтому брать адреса противопоказаны.

• Поскольку это временно, мы не можем тривиально преобразовать в объект ostream посредством приведения.

• И конструктор [очевидно], и str() являются методами класса ostringstream. (Да, нам нужно использовать .str(). Непосредственное использование объекта ostringstream приведет к вызову ios::operator void*(), возвращающему хорошее / плохое значение, подобное указателю, а не строковый объект.)

• operator<<(...) существует как унаследованные ostream методы и как глобальные функции. Во всех случаях он возвращает ostream& ссылку.

• Здесь для ostringstream()<<"foo" доступны унаследованный метод ostream::operator<<(void* ) и глобальная функция operator<<(ostream&,const char* ). Унаследованный ostream::operator<<(void* ) выигрывает, потому что мы не можем преобразовать ссылку на объект ostream для вызова глобальной функции. [Престижность coppro!]

Итак, чтобы это осуществить, нам необходимо:

• Выделить временный ostringstream.
• Преобразуйте его в ostream.
• Добавить данные.
• Преобразуйте его обратно в ostringstream.
• И вызовите str().

Распределение: ostringstream().

Преобразование. Есть несколько вариантов. Другие предложили:

• ostringstream() << std::string() // Kudos to *David Norman*
• ostringstream() << std::dec // Kudos to *cadabra*

Или мы могли бы использовать:

• ostringstream() . seekp( 0, ios_base::cur )
• ostringstream() . write( "", 0 )
• ostringstream() . flush()
• ostringstream() << flush
• ostringstream() << nounitbuf
• ostringstream() << unitbuf
• ostringstream() << noshowpos
• Или любой другой стандартный манипулятор. [#include <iomanip>] Ссылка: см. «Вставить данные с форматом» 1/3 нижней части этой веб-страницы.

Мы не можем использовать:

• operator<<( ostringstream(), "" )
• (ostream &) ostringstream()

Добавление: Теперь все по порядку.

Обратное преобразование. Мы могли бы просто использовать (ostringstream&). Но dynamic_cast будет безопаснее. В маловероятном случае dynamic_cast возвращается NULL (не должно), следующее .str() вызовет дамп ядра.

Вызов str(): предположить.

Собираем все вместе.

#define FORMAT(ITEMS)                                             \
  ( ( dynamic_cast<ostringstream &> (                             \
         ostringstream() . seekp( 0, ios_base::cur ) << ITEMS )   \
    ) . str() )

Использованная литература:

• Библиотека IOstream
• ostringstream
• ostream::operator<<()
  
  
• Руководство по преобразованию типов
• Wiki: преобразование типов

.

Вот что я использую. Все это укладывается в одно аккуратное определение класса в файле заголовка.

обновление: значительное улучшение кода благодаря litb.

// makestring.h:

class MakeString
{
    public:
        std::stringstream stream;
        operator std::string() const { return stream.str(); }

        template<class T>
        MakeString& operator<<(T const& VAR) { stream << VAR; return *this; }
};

Вот как это используется:

string myString = MakeString() << a << "b" << c << d;

Проблема, с которой вы столкнулись, связана с тем, что operator << (ostream&, char*) не является членом ostream, и ваш временный экземпляр ostream не может привязаться к ссылке, отличной от const. Вместо этого он выбирает перегрузку void*, которая является членом ostream, и поэтому не имеет этого ограничения.

Лучшим (но не самым простым или элегантным, с любой точки зрения!) Было бы использование препроцессора Boost для генерации большого количества перегрузок функций, каждая из которых была построена на большом количестве объектов (включая были опущены и предполагалось using namespace std;) :

#define MAKE_OUTPUT(z, n, data) \
    BOOST_PP_TUPLE_ELEM(2, 0, data) << BOOST_PP_CAT(BOOST_PP_TUPLE_ELEM(2, 1, data), n);

#define MAKE_FORMAT(z, n, data) \
    template <BOOST_PP_ENUM_PARAMS_Z(z, BOOST_PP_INC(n), typename T)> \
    inline string format(BOOST_PP_ENUM_BINARY_PARAMS_Z(z, BOOST_PP_INC(n), T, p)) \
    { \
      ostringstream s; \
      BOOST_PP_REPEAT_##z(z, n, MAKE_OUTPUT, (s, p)); \
      return s.str(); \
    }

Точная работа не гарантируется (написал без тестирования), но в этом суть. Затем вы вызываете BOOST_PP_REPEAT(N, MAKE_FORMAT, ()), чтобы создать серию функций, принимающих до N параметров, которые будут форматировать вашу строку так, как вы хотите (замените N целым числом по выбору. Более высокие значения могут отрицательно повлиять на время компиляции). Этого должно хватить, пока вы не получите компилятор с вариативными шаблонами. Вы должны прочитать документацию по препроцессору ускорения, в ней есть очень мощные функции для подобных вещей. (впоследствии вы можете #undef макросы после вызова BOOST_PP_REPEAT для генерации функций)

Вот такой ответ, как у cadabra, который не влияет на состояние ostream:

#define FORMAT(items)     static_cast<std::ostringstream &>((std::ostringstream() << std::string() << items)).str()

Я считаю, что первый абзац ответа Coppro описывает, почему вещи так себя ведут.

Вот рабочее решение:

#define FORMAT(items)                                                   \
   ((std::ostringstream&)(std::ostringstream() << std::dec << items)).str()

Я не совсем понимаю поведение первого аргумента.

Когда я взял решение mrree (помеченное как «предпочтительное», прекрасно объясненное и отлично работающее с G ++), я столкнулся с проблемами с MSVC ++: все строки, созданные с помощью этого макроса, оказались пустыми.

Через несколько часов (и многочасового почесывания головы и задавания вопроса "перезагрузить" здесь) я обнаружил, что виноват вызов seekp (). Я не уверен, что MSVC ++ делает по-другому с этим, но заменяя

ostringstream().seekp( 0, ios_base::cur )

с кадабрами

ostringstream() << std::dec

работает и для MSVC ++.

Почему бы просто не использовать функцию вместо макроса?