Почему потоки в C++?

Потоки имеют лучшую безопасность типов.

Например, printf("%s", a); может пойти ужасно неправильно, если a является целым числом. cout << a; не имеет этой проблемы.

Другая проблема заключается в том, что потоки лучше соответствуют методологиям объектно-ориентированного проектирования.

Например, у вас есть простое приложение, которое записывает некоторый вывод, а затем вы хотите, чтобы вывод направлялся в файл, а не в консоль. С вызовами C вам придется заменить все вызовы printf вызовами fprintf и позаботиться о поддержании FILE* на этом пути. С потоками вы просто меняете конкретный класс потока, который вы используете, и все, большая часть кода остается такой же:

void doSomething(ostream& output)
{
   output << "this and that" << a;
}

doSomething(cout);
doSomething(ofstream("c:\file.txt"));

Во-первых, он позволяет использовать объектную модель C++ для создания функций, которым все равно, что они пишут: в стандартный вывод, в файл или в сетевой сокет (если у вас есть сетевой сокет, производный от ostream). Например.

void outputFoo(std::ostream& os)
{
  os << "Foo!";
}

int main()
{
  outputFoo(std::cout);

  std::ofstream outputFile("foo.txt");
  outputFoo(outputFile);

  MyNetworkStream outputSocket;
  outputFoo(outputSocket);
}

И аналогично для входных потоков.

Потоки также имеют преимущество, когда речь идет о вводе и выводе объектов. Что произойдет, если вы захотите прочитать объект с помощью scanf?

MyObject obj;
scanf("??", &obj); // What specifier to use? 

Даже если бы существовал соответствующий спецификатор, как scanf узнал бы, как заполнить члены объекта? С потоками C++ вы можете перегрузить operator<< и написать

MyObject obj;
std::cin >> obj;

И это сработает. Аналогично для std::cout << obj, так что вы можете написать код сериализации объекта в одном месте и не беспокоиться об этом где-либо еще.

Потоки C++ типобезопасны. В C, если вы скажете:

double d = 1.23;
printf( "%d", d );

вы не гарантируете, что получите сообщение об ошибке, даже если преобразование неверно.

Кажется, вы задаете очень простые вопросы по С++. Какой учебник C++ вы используете, который не охватывает их?

printf не является типобезопасным для одного. Интерфейс cout также является более универсальным, что позволяет использовать многие функции, недоступные в версии printf. Одним из замечательных примеров является то, что ваш оператор потока для ваших типов, если вы все делаете правильно, ссылается на std::ostream как на поток, а не на cout. Таким образом, вы можете изменить назначение вывода, просто используя другой поток. Чтобы сделать это с помощью printf, вам нужно сделать много зависящих от платформы перезаписей выходных дескрипторов.

Я также думаю, что все эти строковые абстракции в C++ компилируются в (менее эффективные) стандартные вызовы функций в двоичном формате.

Думай сколько хочешь. Пока вы не проверите свое предположение, ваше мнение не будет иметь большого веса. Кроме того, вам нужно учитывать потерю абстракции, что обычно намного важнее в современной разработке программного обеспечения.

Помимо безопасности типов и полиморфности, потоки более переносимы. В некоторых системах printf с длинной требует «%d», а в некоторых системах — «%ld».

Потоки могут быть объединены в цепочку

cout << "hello" << " " << "world"

Еще одним преимуществом потоков является то, что их можно расширять. С потоками вы можете заставить свои пользовательские классы работать так же, как встроенные типы:

class foo { ... };

ostream &operator<<(ostream &ostr, const foo &f)
{
    ostr << ... how you want to print a foo ...;
    return ostr;
}

И теперь вы можете напечатать foo, как и все остальное:

int n = ...
foo f = ...

cout << n << ": " << f << endl;

C++ IOStreams являются смехотворно неэффективными (в большинстве известных мне реализаций). Часто это не проблема, но когда это проблема, библиотека практически бесполезна. Также хорошо, что синтаксис не интуитивно понятен (и очень, очень многословен). Библиотека сложна и ее трудно расширять. Тоже не очень гибкий. По сравнению с чем-то вроде STL IOStreams действительно выглядит как страшный сон. Но это здесь, и мы застряли с этим.

Причина, по которой он здесь, и причина, по которой он выглядит так, заключается в том, что он был разработан раньше, до того, как C++ стал зрелым языком. До этого у нас был многолетний опыт, рассказывающий нам, что такое хороший дизайн библиотеки, а что нет. Прежде чем кто-либо действительно знал, какие варианты были.

C++ нуждалась в библиотеке ввода/вывода, которая была лучше, чем C. И в некоторых важных отношениях C++ IOStreams лучше. Как уже упоминалось, они безопасны для типов и расширяемы. Реализуя один оператор, я могу распечатать определяемый пользователем класс. Этого нельзя было сделать с printf. Мне также не нужно беспокоиться о неправильном определении спецификаторов формата и выводе мусора из-за отсутствия безопасности типов.

Эти вещи необходимо исправить. И эй, в первые дни виртуальные функции и перегрузка операторов были дерьмом. Это выглядело круто. Конечно, библиотеки хотели использовать эти возможности.

Библиотека IOStreams представляет собой компромисс между:

• что-то более безопасное и расширяемое, чем C stdio.h
• что-то эффективное
• что-то хорошо продуманное и интуитивно понятное
• библиотека, которая фактически существовала во времена стандартизации C++. (они должны были что-то добавить, поэтому им пришлось выбирать между кандидатами, которые действительно существовали в то время.)

Библиотека не достигает всего этого, и я считаю, что сегодня, с нашим многолетним опытом работы с языком, мы могли бы разработать гораздо лучшую библиотеку. Но еще в середине 90-х, когда они искали библиотеку ввода-вывода для добавления, это было лучшее, что они могли найти.

Потоковый синтаксис с operator<< и operator>> обеспечивает хорошую конкатенацию.

printf("%d%d%d%d%d", a, b, c, d, e);

vs

cout << a << b << c << d << e;

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

Между прочим, C++ позволяет вам использовать printf. Так что, если вам это нравится, продолжайте и используйте его.

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

Допустим, у вас есть сложный объект, который вы хотите записать в консоль вывода, в файл журнала и во всплывающее окно отладки. Собираетесь ли вы написать три функции, которые делают почти одно и то же, или вы собираетесь написать одну функцию, которой вы передаете выходной поток?

На самом деле

cout << "Test: " << test << endl;

кажется мне более интуитивным, чем

printf("Test: %d\n", test);

Если вы никогда раньше не видели printf, вы никак не узнаете, что он делает.

В любом случае,

print "Test: " + test

(на нескольких языках включая Python :() имеет намного больше смысла :)

Я до сих пор использую printf, главным образом потому, что с его помощью легко контролировать формат вывода.

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

Я также не согласен с другой причиной, по которой поток претензий более гибок из-за взаимозаменяемости. Это эквивалентно рекомендации использовать fprintf(fout,...) для взаимозаменяемости. Если вам нужно перенаправить вывод, используйте канал. Если вы находитесь в библиотеке, почему бы вам просто не вернуть строку и позволить вызывающей стороне решить, куда она пойдет?

stringstream безопаснее, чем snprintf/sscanf, потому что полностью исключает возможность переполнения буфера (даже "мягких сбоев").

Потоки работают с шаблонами, а printf/scanf — нет.