сотреть iostream

f<<«somestring»;

Текстовый поток, или как там его. Объявил, а потом potok<<«primitiv», если я тебя правильно понял.

Внезапно

[code=cpp] #include <iostream> #include <sstream>

int main() { std::stringstream s;

s << «Hello» << '\t' << «world» << '\xa';

std::clog << s.str();

return 0; } [/code]

Зачем аналог?

Нужен «правильный» аналог s*printf.

А что тебе мешает использовать s*printf?

> А что тебе мешает использовать s*printf?

Ну плюсы это религия же.


ТСу: Используй удобный, Ъ-шный s*printf, а не плюсовые велосипеды, и будет тебе счастье.

> А что тебе мешает использовать s*printf?

Как его использовать в шаблоне, что писать в строке форматирования? Всё приводить к «%s»? :)

Ещё вот так можно, если я правильно задачу понял:

#include <boost/lexical_cast.hpp>
std::string somestring = boost::lexical_cast<std::string>(something);

Потоки

sprintf не умеет работать с собственными типами данных

IOStreams
Boost.Format
Loki.SafeFormat
FastFormat
QString
etc.

>А что тебе мешает использовать s*printf?

ну какгбе C++ это другой язык.

> ну какгбе C++ это другой язык.

т.е. вам мешает исключительно только собственное мнение, что С++ это другой язык?

Плюсану за iostrem.

sprintf - зло

snprintf - немного лучше

std::stringstream - немного медленнее и потребляет дополнительную память, но зато безопасно и в духе с++. К тому же можно использовать в шаблонах.

Дальше сам думай.

> Вроде есть в плюсах stringstream, и из него можно брать числа, строки и т.п., т.е. что-то вроде sscanf. А нужно наоборот из примитивных значений сконструировать строку.
Use std::ostringstream, Luke!
Ну по крайней мере вы его просите.

Это не моё собственное мнение - так и есть. А тех, кто не разделяет C и C++ - надо насмерть расстреливать на ближайшем электрическом столбе

Почему еще никто не вспомнил про *printf_s ?

> Плюсану за iostrem.

иострём

Тонко.

sstream vs snprintf

> std::stringstream

медленнее

потребляет дополнительную память

и в духе с++

можно использовать в шаблонах.

→ Дух C++: медленный, жрущий память и с шаблонами!

можно пользоваться snprintf. Есть стримы которые используют готовый буфер без дополнительной памяти. Вопрос на засыпку - локализация?

Какие нынче толстые анонимусы пошли...

Ой, что это такое?

$ apropos printf_s

printf_s: nothing appropriate

Нету :( Боюсь, месье, вы ошиблись форумом. Гугл считает, что вам - на винфак

Как уже сказали: юзай stringstream. А для всяких штучек типа:

sprintf(str, "%3.3d", my_int)

> Какие нынче толстые анонимусы пошли...

Сам сказал. Из песни слов не выкинешь. Я тут не причём

p.s. у вас С++ ГМ? Оденьте шапочку из фольги (непременно двухслойную), прекратите писать (и даже более того - громко думать) о С++

> Это не моё собственное мнение - так и есть

я о том, что стандартную библиотеку С еще никто не отменял, только из-за того, что С++ это не С

А тех, кто не разделяет C и C++ - надо насмерть расстреливать на ближайшем электрическом столбе

какие вы нервные :)

> можно использовать манипуляторы

О да, это в разы (раз этак в 10) удобнее, чем стандартное форматирование ввода/вывода Си. И занимает где-то в столько же больше места. В исходнике и в рантайме. Ладно, в райнтайме не так всё страшно. Но в чём выгода в этом извращении? Почему нельзя простые вещи делать просто?

http://doc.qt.nokia.com/latest/qstring.html#arg

> Это не моё собственное мнение - так и есть.

Ваше-ваше. Может, по-вашему, вообще стоит запретить пользоваться Сишными стандартными (заметьте, стандартными, не взирая на компилятор и версию компилятора) ABI для вызова внешних функций? Вы очень забавны в своих заблуждениях :p

А тех, кто не разделяет C и C++ - надо насмерть расстреливать на ближайшем электрическом столбе

Ооо да! Повесить вас на электрическом стуле. Снова феерический бред :]

> http://doc.qt.nokia.com/latest/qstring.html#arg

Qt - это самая приятная из C++ библиотек, с которыми я сталкавился. В использовании, в навигации по документации, в поддержки «из коробки» - на высоте - рулит и педалит

За все нужно платить. sprintf небезопасный, но быстрый. std::stringstream безопасный, но немного медленнее. Тут уж выбирай что тебе нужно. Есть еще std::sstream, который может использовать существующий буфер, но его хотят исключить из стандарта, так что использовать его можно на свой страх и риск. Вообще, лучше все таки использовать std::stringstream до тех пор, пока не доказано реальное снижение скорости работы программы. Вот тогда для оптимизации можно сделать замену на snprintf.

П.С. anonymous, хватит трепаться. Если хочешь выразить свою точку зрения, то аргументируй ее.

/std::sstream/std::strstream

Но в чём выгода в этом извращении? Почему нельзя простые вещи делать просто?

Можно, но ТС спросил, как «извратиться и сделать сложно» - я ответил.

> sprintf небезопасный

в кривых руках всё опасно.

У кого-то есть прямые руки? Они у всех кривые, иначе бы слова patch не существовало бы.

snprintf, если нет каких-то существенных противопоказаний. iostream конечно одна из заповедей Страуструпа, но раза в два менее удобен в использовании (раза в два больше приходится топтать), про размер бинарников и быстродействие не говорю.

Да, надо правильно указывать шаблон -а что, в статически типизируемм языке непонятно какой тип у аргумента?;-)

Для сложных собственных объектов все чуток сложнее, но тоже лечится. Вот кстати вопрос к сообществу - есть метод класса, возвращающий const char* (форматированное представлени объекта). Как быть со сборкой мусора?;-) Я выкрутился сделав глобальный кольцевой буфер, других идей в голову не пришло... Т.е. я хочу писать что то вроде

printf( "... %s ...", myobject.c_str() )

всякие std::string не канают, т.к. насколько я понимаю созданный на стеке метода объекта string сдохнет вместе с результатом его string::c_str()?

Любителям вывода полиморфных классов через iostream - все равно придется ж перегружать внешний оператор вывода для интерфейса через некую виртуальную ф-ю, и потом раскручивать ее у наследников, так что то на то и выйдет.

Ты типа такого хочешь?

vector <char> v (size, '\0');
printf( "... %s ...", &* v.begin ());
std::string str (v.begin (), find (v.begin (), v.end (), '\0'));

> всякие std::string не канают, т.к. насколько я понимаю созданный на стеке метода объекта string сдохнет вместе с результатом его string::c_str()?

Локальный string сдохнет, а его возвращенная копия останется. Например, в следующем коде никаких проблем с временем жизни объектов нет:

string SomeClass::someMethod() { string s = «hello!»; return s; }

Насколько я понял пример - нет.

я типа такого хочу:

class vector3D{
public:
double x, y, z;
...
const char* c_str();
}
...

vector3D a;
...
printf("... a=%s ...", a.c_str() );

как сделать vector3D::c_str() с т.з. сборки мусора?

Копия то останется, но копию то я в printf не запихну, я запихну c_str() от копии, а копия тоже сдохнет и утянет за собой возвращенный буфер.

Дык сначала выполнится printf, а потом уже помрет объект. В чем собственно проблема?

Другой вариант можно хранить строковое представление в самом объекте классе, тогда класс ответственен за освобождение с памятью.

Одним словом проблемы у вас надуманные так же как и их решения.

> За все нужно платить. sprintf небезопасный, но быстрый.

Тебе открыть глаза, что delete/delete[]/new/new[]/ так же операции разыменования - небезопасные? Что, теперь их не использоваться? В чём вообще небезопасность семейства функций sprintf? Длина буфера для вывода - задаётся и ограничивается, в чём же небезопасность-то??

П.С. anonymous, хватит трепаться. Если хочешь выразить свою точку зрения, то аргументируй ее.

Ты хочешь, чтоб я аргументировал твои собственные слова? Ты там в своём уме? Сам же написал, а теперь пытаешься отнекиваться? Мдя.

Блин, с примером перемудрил. :) Это действительно не то. Это пример как не заморачиваться с созданием и уничтожением буфера для функций типа someFunction (char *buf, size_t bufSize);

Во первых не факт - вполне может сначала объект сдохнуть, а потом printf выполнится, даже скорей всего так и будет (наск мне помнится). Во вторых писать

printf( ..., a.to_std_str().c_str() ) как то громоздко...

> В чем собственно проблема?

Проблема в том, что у человека не хватает элементарных знаний языка С++, вот он и придумывает себе проблемы которых нет.

sprintf
Длина буфера для вывода - задаётся и ограничивается

Ты в своем уме? Не путаешь с snprintf?

Вот как раз основная проблема у sprintf - переполнение буфера.

> Другой вариант можно хранить строковое представление в самом объекте классе, тогда класс ответственен за освобождение с памятью.

Я плакаль... Вы пример то посмотрели??? Представляете себе, 10^8 декартовых векторов, и в каждом еще как мин пойтер на стрковое представление???

Одним словом проблемы у вас надуманные так же как и их решения.

АНаимусу не привыкшему думать все кажется надуманным... зачем Вам С++, идите ужо на С# или яву, там все так просто.

void function () {
  SomeObject o;
  printf ("blja", o.c_str ());
}

И как o может сдохнуть раньше?

Не тратьте на этого ананимного придурка время, видимо еще один ВыскоПрофессиональныйПрограммист-недоучка с дипломом, к тому же хамло, к-му нечем занятся.

> вполне может сначала объект сдохнуть, а потом printf выполнится, даже скорей всего так и будет (наск мне помнится)

Локальный нестатический объект сдохнет когда выйдет из области видимости, временный объект сдохнет в конце полного выражения (full expression). Идите и учите язык.