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

Проблема, с которой вы столкнулись, связана с тем фактом, что 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 для генерации функций)

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

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

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

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

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

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

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

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

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

// 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;

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

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

• Мы играем с временным объектом 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 для вызова глобальной функции. [Слава коппро!]

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

• Разместите временный 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: Приведение типов

.

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

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

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

с кадабрами

ostringstream() << std::dec

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