> охохо, во-первых, как с помощью printf Вы это сделаете - очень интересно :)

переопределит оператор приведения типа?

ну и код в студию, плиз, я не представляю как, вот заодно и поучусь :)

printf( "...%s...", (char*) MyContaner );

хотя конечно это бред, достаточно метод

printf( "...%s...", (char*) MyContaner );

а?? как вы класс приведёте к (char*)?

и не вижу конвертации в обратную сторону

> а?? как вы класс приведёте к (char*)?

operator char*()

и не вижу конвертации в обратную сторону

«fprint или cout»

> а?? как вы класс приведёте к (char*)?

operator char*()

а, точно :)

> и не вижу конвертации в обратную сторону

«fprint или cout»

не понял

> не понял

наверное это я не понял, вы имели ввиду scanf или что-то другое?

я про это

так вроде тут printf вообще не причем, не?

да разговор начался с того что «фигня Ваш std::cout, я пользуюсь printf», некоторые товарищи тут не согласились, дальше по теме :)

на мой взгляд фишка в том что парадигма потоков (и в частности istringstream и ostringstream на которые был намёк) является более предпочтительной при использовании С++, в отличие от...

boost::format!

А вместо cin/scanf - boost::spirit =).

write/writeln

/thread

P.S. Тред не читал, но осуждаю.

> а в случае с printf?

printf(«A[%s]\n», obj.toString.c_str());

так меньше писать и гораздо понятней смотрится

Что вы предпочитаете: С или С++ ?

Э, так вопрос, я бы сказал, поставлен некорректно.
Или я неправ?

Пишу на с++, но до этого использовал сишный fprint. Решил перейти на cout. Оказалось не так с ним все пушисто и красиво. Одно лишь форматирование уже «доставляет».

std::cout << "A[" << std::setw(4) << i << "] = " << std::setw(23) << std::setprecision(16) << A[i] << std::endl;

уж слишком много кода, тяжело отделить вывод от форматирования, не наглядно. Теряется красота кода.

http://library.gnome.org/devel/glibmm/stable/classGlib_1_1ustring.html#_details

struct Foo
{
    int a;
    int b;

    std::ostream &dump(std::ostream &os) const
    {
        os << "a=" << std::dec << a << ", b=" << b;
        return os;
    }
}

static inline std::ostream &
operator << (std::ostream &os, const Foo &f)
{
    return f.dump(os);
}

Foo f;
std::cout << "Foo is (" << f << ")" << std::endl;

Попробуй сделать нечто подобное на printf().

PS: Да, близкое по смыслу можно. Но будет заметно более жручим.

Я делаю friend обычно

Я делаю friend обычно

А именно?

Ну так надо пользоваться чем-то третьим, объектным, но не уродским ;)

Ну так надо пользоваться чем-то третьим, объектным, но не уродским ;)

Ну например? boost::format? Он тоже далек от идеала.

Лень сейчас с первого раза правильно печатать.

Типо такого

http://www.softboard.ru/lofiversion/index.php/t62725.html

Не знаю, плюсами почти не пользуюсь. Предпочитаю С или какой-нибудь питон.

Типо такого http://www.softboard.ru/lofiversion/index.php/t62725.html

Если честно многа букф по ссылке читать даже не пробовал. Но к чему именно относилось 'я обычно использую friend' все равно не понял. Можно по-простому в 2х словах?

Это я просто так сказал. friend позволила бы сразу залезть внутрь класса без функции dump. Не суть важно, просто сокращение кода

Это я просто так сказал. friend позволила бы сразу залезть внутрь класса без функции dump. Не суть важно, просто сокращение кода

Ну это уже детали. Причем что иметь отдельный dump бывает полезно.

std::cout << "A[" << std::setw(4) << i << "] = " << std::setw(23) << std::setprecision(16) << A[i] << std::endl;

уж слишком много кода, тяжело отделить вывод от форматирования, не наглядно. Теряется красота кода.

всё что Вы назвали - очень субъективно, от отсутствия опыта Вам все эти буквы кажутся страшными и непонятными

не буду Вас убеждать, но вот мой Вам совет (Вы его вольны проигнорировать :)) - осильте концепцию потоков (на практике, желательно) и, возможно, Вы почувствуете логику и красоту подобного подхода

так [..] гораздо понятней смотрится

только для Вас, только для Вас

Это я просто так сказал. friend позволила бы сразу залезть внутрь класса без функции dump. Не суть важно, просто сокращение кода

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

и да, смотрим сюда

Не убедительно. Если нужно типо-безопасное решение, то есть QString.arg, который гораздо лучше смотрится чем «потоки».

Не все так плачевно. Дело в том, что я ведь делаю френда в самом классе. Изменилась структура - переписал френда. Так же как автор до того бы переписывал функцию dump. Это по настоящему все не делает большой разницы

есть QString.arg, который гораздо лучше смотрится чем «потоки»

эм, не уверен что QString().arg().arg().arg().arg() выглядит лучше

Не все так плачевно. Дело в том, что я ведь делаю френда в самом классе. Изменилась структура - переписал френда. Так же как автор до того бы переписывал функцию dump. Это по настоящему все не делает большой разницы

простите, но я уже запутался, не могли бы Вы привести небольшой кусочек кода

Лучше хотя бы потому, что сама строка, которая выводится видна стразу и не надо в уме складывать все эти скобочки, стрелочки и модификаторы.

Лучше хотя бы потому, что сама строка, которая выводится видна стразу и не надо в уме складывать все эти скобочки, стрелочки и модификаторы.

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

Не только мой, но и опыт моих коллег. Я не понимаю что вы мне пытаетесь доказать? Что есть говно это вкусно? Я вам не поверю, даже если у вас огромный опыт говноедения и вы утверждаете, что это вкусно.

http://www.parashift.com/c++-faq-lite/input-output.html#faq-15.9

Не только мой, но и опыт моих коллег.

не существенно

Я не понимаю что вы мне пытаетесь доказать?

я пытаюсь показать что в Вас говорит раб своей привычки, не больше :) и Вы не осознаёте опасности __VA_ARGS__ и не работали плотно с обработкой ошибок ввода/вывода, иначе бы не говорили бы странные вещи

а доказывать Вам что-либо у меня нет ни времени ни желания, в конце концов мне то что, нравится/устраивает - пользуйтесь, так что это не про Вас, а про топикстартера

Что есть говно это вкусно?

Вы просто толстый тролль, ну очень толстый :)

Когда увидел это уродство первый раз, то долго смеялся. Потом правда понял, что причина вообще-то есть, мне кажется. Если сделать по-человечески через <<, что фактически то же самое, только удобнее, то не будет ли конфликта с оператором << вывода в поток? Я ничего не утверждаю, сам не проверял. Просто версия

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

До гемора не доходило, пока что метод работал хорошо в любых случаях. Я просто не могу сейчас навскидку придумать где бы могла возникнуть проблема... Ну понятно, что если я в френде вывожу переменную типа шаблона через cout, то она в свою очередь должна это поддерживать. Тоесть тоже содержать френд или что-то в этом роде. Если не содержит, то ошибка из разряда острелить себе ноги. И другие методы так же проблему не решают.

Если ошибка будет, то другое дело ужасное сообщение о ошибке, но кто говорил что С++ прекрасен?

Ох мля, не Вам судить о том с чем я работал и с чем я не работал и что я осознаю, а что не осознаю. Тут дело не в привычке, а в элементарных удобствах и читабельности.

Если нужна безопасность, то для этого есть более красивые решения нежели iostream.

Когда iostream суют в каждый hello-world и это приводит к невероятному раздуванию кода и усложнению понимания, то это действительно объясняется либо отстуствием опыта либо непробиваемой глупостью.

Потом правда понял, что причина вообще-то есть, мне кажется.

есть, и это желание сделать format string как в printf или boost::format (или как там его)

сделать по-человечески через <<, что фактически то же самое, только удобнее

не совсем, проблема format string возникает когда количество аргументов не определено или может изменяться :)

Вы вообще не признаете iostream? Или признаете в каких-то случаях?

Я говорил о синтаксисе QString(...) << 2 << 4 << «test» << myObj;

Есть вменяемые вещи на iostream, например, lexical_cast, но в 90% случаев iostream не нужен.

Тоесть вы предлагаете создать создать нужный QString и потом его в char* и в printf?

не Вам судить о том с чем я работал и с чем я не работал

уж простите великодушно, это было просто предположение :)

не Вам судить [..] и что я осознаю, а что не осознаю.

а что делать если Вы с упорством маньяка приводите одни и те же субъективные доводы и наивно считаете что все вокруг должны в них также свято верить как и Вы?

Тут дело не в привычке, а в элементарных удобствах и читабельности.

я не испытываю никаких затруднений, странно правда? и даже, студенты не испытывают, что же тут не так? может Ваши личные предпочтения и привычки мешают взглянуть на проблему объективно?

скажу более, для людей которые равно не знаю ни про std::cout ни про printf, именно printf имеет куда более нечитаемый вид

Если нужна безопасность, то для этого есть более красивые решения нежели iostream.

так в студию, или оно секретное?

Когда iostream суют в каждый hello-world и это приводит к невероятному раздуванию кода и усложнению понимания, то это действительно объясняется либо отстуствием опыта либо непробиваемой глупостью.

давайте про глупость не будем, да? глупых примеров можно десять миллиардов придумать

iostream в hello world нужен для того чтобы объяснять студентам и сиплюсплюсолюбознательныи что такое потоки и как правильно организовывать ввод/вывод данных в С++, но великим учёным мужам вроде Вас не интересны проблемы тараканов, да?