Говорят, cin.sync_with_stdio(0); в начале программы здорово ускоряет ввод/вывод через cin/cout.

Можно писать ios_base::sync_with_stdio(false), но scant/printf все равно быстрее.

Самое время научиться использовать scanf/printf. Тем более, когда-то же надо начинать. И там нет ничего сложного, а программу они и правда ускоряют по сравнению с cin/cout.

Интересно услышать мнение людей, имеющих большой опыт и олимпиадного, и промышленного программирования, насчёт такой стороны вопроса.

Насколько я понимаю, использование scanf/printf приводит к потенциальным проблемам не только по причинам %lld versus %I64d. А ещё и потому, что возникает зависимость от типа в таких местах, где по современным методологиям программирования никаких зависимостей быть не должно. Писать template-ом потребует о-о-очень больших извращений, при ручной замене типа возникает лишнее место где можно налажать, и т д

Разумеется, это не отменяет факта, что действительно бывают ситуации, где scanf/printf таки заметно ускоряет.

Так что, IMHO, scanf/printf должны быть исключением (а не правилом), ориентированным только на случаи: (а) ввод/вывод критично влияют на время работы программы в целом; (б) есть достаточные гарантии, что типы не будут меняться, и при этом нужно форматирование, которое printf-ом делается таки проще, например printf("%d %2d:%02d:%02d.%03d",days,hours,minutes,seconds,milliseconds).

Кстати, ещё одна ситуация, где scanf/printf-ами реально можно налажать — написать в Visual Studio %lf для long double, а потом удивляться, почему не работает под другими компиляторами.

сin и cout используют потоки, должны ещё определить тип переменной с которой работают. В scanf и printf мы указываем тип переменной и поэтому scanf и printf не тратят время на определение типа пременной. Они не используют потоки. Засчёт всего этого scanf и printf выигрывают время. Но у scanf есть недостаток. Если нужно ввести массив букв известного размера, элементы которого разделены пробелом то scanf считает пробел за элемент массива и нужно писать проверку на пробел в таком случае. ( а у cin такой проблемы нет) . Зато с помощью scanf и printf можно легко узнать код почти любого символа (даже пробела и клавиши Enter).

' #include ' ' #include '
' using namespace std; ' ' int main()
' { ' ' char c; ' ' scanf("%c",&c); ' ' printf("%d",c); ' ' return 0; ' ' } '

Раз уже эта извечная тема не утихает, спрошу здесь заодно. Влияет ли на скорость считывания/записи изменение размера внутреннего буфера потока в iostreams? Теоретически, если мы знаем, что будет много данных, мы можем пробовать считать больше за один системный вызов и таким образом экономить время.

Как-то так:

const int bufsize = 64 * 1024;

char *buf = new char[bufsize];

cin.rdbuf()->pubsetbuf(buf, bufsize);

У себя (GCC, Linux) я пробовал разные значения от 1 до 10M и не обнаружил никакой разницы на больших массивах данных, что представляется весьма странным (pubsetbuf возвращает ОК).