почему в C++ используют потоки для ввода-вывода?

Почему, собственно, народу не угодили обычные libc-функции типа printf/sprintf/scanf?

Сложнее добавить поддержку произвольных типов.

Не нравятся потоки/не понимаешь, почему они лучше - никто не мешает сделать

#include <cstdio>
using std::printf;

//...
printf(...);
//...

так и делаю, но вот смутные сомнения в правильности подхода терзают.

std::printf входит в стандарт C++, не парься.

И да, много ситуаций, когда потоки удобны, или труднозаменимы чем либо. См. Protobuf, например

ну вот мне надо пакет распечатывать. Автор библиотеки за меня решил, в каком виде его распечатывать — типа жри, что дают?

Ну, там как-то так:

RMAPPacket p;
...
std::cout << p << std::endl;
...

И что, потоки только ради этого придумали?

данные в протоколе tcp - это поток байт, согласно стандарту. Многое другое тоже удобно представимо в виде абстракции stream.

Если тебя устраивает то, что дают (а в большинстве случаев это так) - жри что дают. Не устраивает - переопредели оператор << для этого типа. Код переписывать не придется. Совсем наркоман - выводи поля по одному, никто не запрещает.

видимо, совсем наркоман ))

Главное, чтоб потом не пришлось в пяти десятках файлов переписывать строки формата и списки параметров printf если поля надо будет местами поменять в выводе или, скажем, десяток новых полей добавить. Или, скажем, в файл выводить, а не в stdout.

1. Как я понимаю, по умолчанию в плюсах для I/O используется iostream?

«По умолчанию» ничего не используется. Как напишешь - так и будет.

2. Форматирование I/O делается с помощью «манипуляторов» типа std::hex, std::endl и прочих?

Если ты хочешь именно так - то да.

3. Почему, собственно, народу не угодили обычные libc-функции типа printf/sprintf/scanf?

С ними проще наделать опасных ошибок. Но тем не менее, никто не запрещает их использовать.

А вообще да, потоки - это самая кривая и нелогичная часть STL.

Делай для каждого нужного типа функцию mystruct_snprint(char *str, size_t size, const mystruct *). Этим ты локализуешь сериализацию твоих типов; в потом использование в Xprintf() или в перегруженных operator<<() - дело техники

На мой вкус, потоки ввода-вывода ужасны, пользоваться, а главное — в дальнейшем читать код с ними, крайне неудобно. Возможно они оказываются клевыми в каких-то задачах (тут говорят про протобуф, я не пользовался), но в качестве форматирования текста это п-ц. printf всем хорош кроме того, что не расширяется произвольными типами. Я однажды вдохновившись CL-овским format-ом сделал аналог на C++11 и до сих пор пользуюсь. В Qt есть вариации форматирования через QString().arg() — не интересовался на счет расширения своими типами, — в бусте тоже что-то есть, мне не понравилось, я уже не помню чем именно.

Ну так плюсеры — те еще мазохисты!

ЕМНП из мемуаров Старструпа одна из причин, это избавиться от функций с переменным числом аргументов.

friend std::ostream & operator << (std::ostream &, const MyClass &)

/thread

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

лютобешено плюсую.

не-не, мне для симуляции простенькой железки тащить Qt или Boost — это уж слишком.

Хватает того, что исходная либа в зависимостях имеет xerces-c.

а чем плохи функции с переменным числом аргументов? Небезопасны?

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

Более того, в виде потока можно представить ту же строку, бинарный in database log, и ещё кучу чего, а оператор нужено будет реализовать только один. А иначе нужно будет реализовывать код как минимум с использованием fprintf и sprintf...

Ну да. Передаваемые аргументы лежат на совести программиста

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

В общем смотри «Дизайн и эволюция С++» глава 8.3.1. Коротко - контроль типов и вывод пользовательских типов

Я однажды вдохновившись CL-овским format-ом сделал аналог на C++11 и до сих пор пользуюсь.

Удваиваю этого товарища, самый удобный из известных мне способов. Правда, я вдохновлялся питоновским format-ом.

Сложнее добавить поддержку произвольных типов.

Что писать для каждого типа функцию to_string, что перегружать для него operator<<, разницы никакой.