.first и .second могут загромождать формулы и строчки.
#define int long long < — нужен не для скорости набора кода, а для того, чтобы быстро убрать переполнение по всему коду
скорость набора кода не является ограничителем
Это, конечно, правда.
на C/C++ практически никто не писал
Сейчас зависит от уровня соревнований и сложности конкретной задачи. На соревнованиях высокого уровня это обычно основной язык. А так, python, Pascal/Delphi тоже используются.
Не применяли или не видели? Не все их используют, естественно. Но они частенько встречаются в коде и это является нормальным, поэтому я сказал, что они стандартные.
На codeforces.com они есть не во всех посылках, но во многих бывают. В московской сборной, если я правильно помню, я видел их у каждого, у кого смотрел код, правда, это было не было порядка 10 людей. Можно посмотреть найти посылки всех людей из московской сборной вместе с остальными на региональном этапе здесь, но их неприятно разгребать. Но сам по себе проход и участие в региональном этапе не делает человека спортивным программистом, поэтому посылки остальных людей в большинстве своем не репрезентативны.
Я верю, что #define-ы на pair<int, int> на бывают разные. По моему субъективному опыту ff и ss самые популярные, но как оказалось после просмотра посылок последнего раунда, это правда только для локального сообщества, в котором я нахожусь. посылка, но это из московской сборной пример 2 пример 3 пример 4
Кажется, что все кроме первого пункта ссылается на прошлую версию моего комментария, который я судорожно пытался изменить в те 30 минут, что дает хабр. Для того, чтобы убедиться, что я не набагал с макросами я сбрасывал буфер после каждого запроса, что замедлило работу программы в 3 раза. Когда я замерял время работы я забыл поменять обратно endl на '\n' и был крайне удивлен ухудшением производительности. Отсюда:
по модулю странной проблемы с макросами
Кажется, что это я криворукий, но пока не знаю, как это сделать нормально.
Да, версия с функцией — на шесть строк длиннее
Казалось бы, наоборот, версия с функцией короче на 2 строки, потому что в ней нет define-ов.
макросы не использовал бы
Я не говорил, что макросы это хорошо или что это плохо.
Обсуждать что там проихсходит при компиляции с -O0 (а это — умолчаение по историческим причинам) бессмысленно.
Видимо, да. Спасибо.
Итого: бенчмарк сравнивал результаты без оптимизаций, которые может делать компилятор. Без них, что никогда не используется, быстрее макрос. С ними, что происходит всегда и везде, код не ухудшает свою производительность при использовании стандартных функций.
Я не прав. Видимо, больше обсуждать по теме здесь нечего.
P. S.
в условиях жёсткой нехватки времени
Тогда используют очень небольшое кол-во макросов, в которых нельзя ошибиться, поскольку не поддерживаешь код и все макросы пишешь либо сам, либо они общепринятые в среде: #define ff first
#define ss second
#define for(i, n) for(int i = 0; i < n; i++)
и не более 5-10 других для сокращения объема кода, чтобы можно было пафосно писать без автодополнений IDE, а код становился более читаемым для спортивных программистов.
Конкретно я пользуюсь только двумя верхними и когда нужно тем, что написан ниже:
Временами используется: #define int long long
если внезапно оказалось, что где-то что-то переполняется, и нужно срочно это исправить.
1. Чем Вы их компилировали и с какими флагими, если они были? Я это делал без флагов.
2. У меня скомпилированный код из первого коммита разный
Я залил бинарники первых исходников на гитхаб. Естественно, я в теории мог пропатчить бинарники или скомпилить не то, что надо. Я не придумал, каким способом можно дать доказательство того, что такие операции произведены не были. Но на других машинах с другими флагами код может соптимизироваться и скомилироваться по-другому.
3. Я затупил и вместо define-а самостоятельно заменил max на if ручками (который Вы назвали другим алгоритмом. Странно, что у якобы разных алгоритмов якобы одиноковый скомпилированный код.) Это был некорректный бенчмарк не на ту тематику. Сейчас я написал нормальный нераскрытый макрос и у меня локально работает за примерно такое же время как и раскрытый макрос ранее
С -Ofast видимо оптимизируется до эквивалентого кода. У меня работает с таким флагом одинаково быстро.
С учетом этих замечаний проапдейтил репозиторий. Это мой первый опыт публикации бенчмарков, спасибо за замечания и напоминания о том, что собственно я должен был сравнивать. Надеюсь, что сейчас все по модулю странной проблемы с макросами нормально.
P. S. Допустил багу во время написания коммента и исправил. Пост переписывал несколько раз.
github.com/AIshutin/cpp-std-benchmark Сейчас (март 2019) в среднем -8% на GNU GCC 8.2. Тестил ДО снизу на больших (1e6 запросов) радномных тестах с операцией взятия максимума на отрезке и изменения в точке. Буду рад, если кто-нибудь потестит у себя локально и сравнит результаты.
Это не правда. В спортивном программировании замена max и min на макросы позволяют немного ускорить код, превращая T/L в OK, если в задаче это критичные операции.
#define int long long < — нужен не для скорости набора кода, а для того, чтобы быстро убрать переполнение по всему коду
Это, конечно, правда.
Сейчас зависит от уровня соревнований и сложности конкретной задачи. На соревнованиях высокого уровня это обычно основной язык. А так, python, Pascal/Delphi тоже используются.
На codeforces.com они есть не во всех посылках, но во многих бывают. В московской сборной, если я правильно помню, я видел их у каждого, у кого смотрел код, правда, это было не было порядка 10 людей. Можно посмотреть найти посылки всех людей из московской сборной вместе с остальными на региональном этапе здесь, но их неприятно разгребать. Но сам по себе проход и участие в региональном этапе не делает человека спортивным программистом, поэтому посылки остальных людей в большинстве своем не репрезентативны.
Вот посылки с последнего раунда на CF:
#define int long long
пример 1
пример 2
пример 3
пример 4
пример 5
Я верю, что #define-ы на pair<int, int> на бывают разные. По моему субъективному опыту ff и ss самые популярные, но как оказалось после просмотра посылок последнего раунда, это правда только для локального сообщества, в котором я нахожусь.
посылка, но это из московской сборной
пример 2
пример 3
пример 4
#define for(i, n)…
здесь For, а не for
здесь тоже For, а не for
здесь он вообще как FOR
Кажется, что этот макрос чаще пишется с большой буквы, что является неожиданностью для меня.
Возможно, что их начали использовать активно не в то время, когда Вы были на олимпиадах.
Казалось бы, наоборот, версия с функцией короче на 2 строки, потому что в ней нет define-ов.
Я не говорил, что макросы это хорошо или что это плохо.
Видимо, да. Спасибо.
Итого: бенчмарк сравнивал результаты без оптимизаций, которые может делать компилятор. Без них, что никогда не используется, быстрее макрос. С ними, что происходит всегда и везде, код не ухудшает свою производительность при использовании стандартных функций.
Я не прав. Видимо, больше обсуждать по теме здесь нечего.
P. S.
Тогда используют очень небольшое кол-во макросов, в которых нельзя ошибиться, поскольку не поддерживаешь код и все макросы пишешь либо сам, либо они общепринятые в среде:
#define ff first#define ss second
#define for(i, n) for(int i = 0; i < n; i++)
и не более 5-10 других для сокращения объема кода, чтобы можно было пафосно писать без автодополнений IDE, а код становился более читаемым для спортивных программистов.
Конкретно я пользуюсь только двумя верхними и когда нужно тем, что написан ниже:
Временами используется:
#define int long longесли внезапно оказалось, что где-то что-то переполняется, и нужно срочно это исправить.
2. У меня скомпилированный код из первого коммита разный
Я залил бинарники первых исходников на гитхаб. Естественно, я в теории мог пропатчить бинарники или скомпилить не то, что надо. Я не придумал, каким способом можно дать доказательство того, что такие операции произведены не были. Но на других машинах с другими флагами код может соптимизироваться и скомилироваться по-другому.
3. Я затупил и вместо define-а самостоятельно заменил max на if ручками (который Вы назвали другим алгоритмом. Странно, что у якобы разных алгоритмов якобы одиноковый скомпилированный код.) Это был некорректный бенчмарк не на ту тематику. Сейчас я написал нормальный нераскрытый макрос и у меня локально работает за примерно такое же время как и раскрытый макрос ранее
С -Ofast видимо оптимизируется до эквивалентого кода. У меня работает с таким флагом одинаково быстро.
С учетом этих замечаний проапдейтил репозиторий. Это мой первый опыт публикации бенчмарков, спасибо за замечания и напоминания о том, что собственно я должен был сравнивать. Надеюсь, что сейчас все по модулю странной проблемы с макросами нормально.
P. S. Допустил багу во время написания коммента и исправил. Пост переписывал несколько раз.
Это не правда. В спортивном программировании замена max и min на макросы позволяют немного ускорить код, превращая T/L в OK, если в задаче это критичные операции.