Используя scanf () в программах C++ быстрее, чем использование cin?

Я не знаю, верно ли это, но когда я читал FAQ на одной из проблемы, обеспечивающей сайты, я нашел что-то, которые вводят мое внимание по абсолютному адресу:

Проверьте свои методы ввода/вывода. В C++, с помощью cin и суде является слишком медленным. Используйте их, и Вы гарантируете неспособность решить любую проблему с достойным объемом ввода или вывода. Используйте printf и scanf вместо этого.

Кто-то может разъяснить это? Действительно использует scanf () в программах C++ быстрее, чем использование cin>> что-то? Если да, который является этим хорошая практика для использования его в программах C++? Я думал, что это было C конкретный, хотя я просто изучаю C++...

113
задан Wayne Koorts 25 June 2009 в 04:05
поделиться

6 ответов

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

Здесь есть очень вкусная статья, написанная Хербом Саттером » The String Formatters из Manor Farm ", который подробно описывает работу таких программ форматирования строк, как sscanf и lexical_cast , а также то, что заставляло их работать медленно или быстро. Это вроде аналогично, вероятно, к тем вещам, которые могут повлиять на производительность между стилями ввода-вывода C и стилем C ++. Основное различие с форматерами, как правило, заключается в безопасности типов и количестве выделений памяти.

42
ответ дан 24 November 2019 в 02:39
поделиться

Существуют реализации stdio ( libio ), которые реализуют FILE * как streambuf C ++ и fprintf как синтаксический анализатор формата времени выполнения. Потоки ввода-вывода не нуждаются в синтаксическом анализе формата времени выполнения, все это делается во время компиляции. Итак, с общими бэкэндами, разумно ожидать, что iostreams будет быстрее во время выполнения.

2
ответ дан 24 November 2019 в 02:39
поделиться

Если вам важны как производительность, так и форматирование строк, обратите внимание на FastFormat Мэтью Уилсона библиотека.

edit - ссылка на публикацию в этой библиотеке: http://accu.org/index.php/journals/1539

6
ответ дан 24 November 2019 в 02:39
поделиться

Проблема в том, что cin имеет много накладных расходов, потому что он дает вам уровень абстракции выше scanf () звонков. Вы не должны использовать scanf () вместо cin , если вы пишете программное обеспечение на C ++, потому что это want cin для. Если вам нужна производительность, вы, вероятно, все равно не будете писать ввод-вывод на C ++.

1
ответ дан 24 November 2019 в 02:39
поделиться

Даже если бы scanf был быстрее, чем cin , это не имело бы значения. В большинстве случаев вы будете читать с жесткого диска или клавиатуры. Загрузка необработанных данных в ваше приложение занимает на порядки больше времени, чем требуется scanf или cin для их обработки.

-1
ответ дан 24 November 2019 в 02:39
поделиться

Я только что провел вечер, работая над проблемой в UVa Online (Factovisors, очень интересная проблема, проверьте это):

http://uva.onlinejudge.org/index. php? option = com_onlinejudge & Itemid = 8 & category = 35 & page = show_problem & problem = 1080

Я получал TLE (превышен лимит времени) на мои заявки. На этих сайтах онлайн-судей по решению проблем у вас есть ограничение по времени в 2-3 секунды, чтобы обработать потенциально тысячи тестовых примеров, используемых для оценки вашего решения. Для таких ресурсоемких задач, как эта, на счету каждая микросекунда.

Я использовал предложенный алгоритм (читайте об этом в дискуссионных форумах сайта), но все еще получал TLE.

Я просто изменил "cin >> n >> m" на "scanf ("% d% d ", & n, & m)" и несколько крошечных "couts"

16
ответ дан 24 November 2019 в 02:39
поделиться