В контейнерах и алгоритмах, использующих operator<, есть понятие эквивалентности (не больше и не меньше). Конечно, это почти всегда совпадает с результатом применения operator==, но теоретически это может быть не так.
MSVS 2017 очень хорошо, я в свое время делал довольно много проверок. Надо только включить соответствующую опцию компилятора (по умолчанию она выключена). Ну в MSVS 2019 надо уже обсуждать поддержку C++20.
Конечно так правильнее. Но C-строки носят скорее иллюстративный характер, а не практический и мне хотелось продемонстрировать hash_combine, которую можно использовать гораздо шире.
MSVS 2017 очень хорошо, я в свое время делал довольно много проверок. Надо только включить соответствующую опцию компилятора (по умолчанию она выключена). Ну в MSVS 2019 надо уже обсуждать поддержку C++20.
Этот вариант обсуждался в одной из книг списка литературы. Он признан неудачным по причине приоритета оператора. У возведения в степень традиционно высокий приоритет, выше чем у умножения, а у ^ довольно низкий, и поэтому надо будет ставить скобки там, где их никто не привык ставить. Надо будет писать 2*(x^2) вместо привычного 2*x^2. Но и, соответственно, куча трудно обнаруживаемых ошибок.
Алгоритм здесь такой. Сначала ищутся точно подходящие нешаблонные функции и конкретизации шаблонов, полные специализации шаблонов на этом этапе вообще не рассматриваются. В нашем случае есть две точно подходящих конкретизации: шаблон 1 для const char* и шаблон 2 для char. Выбирается шаблон 2 как более специализированный. Далее проверяется, нет ли у этого шаблона полной специализации для выведенного аргумента — char. В нашем случае нет, поэтому этот шаблон и выбирается окончательно.
ADL — это стандарт языка и довольно старый. Без него было бы очень неудобно использовать перегрузку операторов. Перегрузке операторов посвящена следующая статья этой серии, которую планирую выложить через несколько дней.
Спасибо! По поводу отсутствия объяснений, ПОЧЕМУ это так работает ответ достаточно традиционный — ограничения объема статьи. C++20 у меня пока в начальной стадии изучения, но уже чувствую, что придется поработать.
Спасибо за интересную информацию. Ну вообще-то параллельная работа двух разных видеокарт достаточно ожидаема, было бы очень странно, если б они мешали друг другу. А такой режим может оказаться актуальным, если надо параллельно обрабатывать несколько 4K потоков.
Статья как раз про декодеры. Исторически сложилось так, что всю жизнь сидел на Intel. С NVIDIA также работал мало. А вот с продукцией AMD практически не имел дела. Про поддержку Radeon в ffmeg вообще не слышал, специально не искал, так как эта поддержка для меня не актуальна.
Спасибо! Очень интересная информация. Исторически сложилось так, что я всю жизнь сидел на Intel (да и сейчас сижу). Было бы очень интересно пощупать AMD, но в обозримом будущем наверное не получится (хоть они и 5 рублей за кило).
Могу сразу сказать, что libx264 и libx265 грузят ЦП на 100%, то есть они без лишних просьб используют все потоки. Аппаратное ускорение они не поддерживают. Кодеры *_qsv работают. (Наверное и их аналоги от Nvidia.) Главная проблема в том, что для кодеров используют большое число параметров, которые влияют на скорость кодирования и надо перебирать все комбинации, так, что подобные таблицы могут быть огромными. Даже если использовать только пресеты (ultrafast, superfast, veryfast, faster, fast, medium, slow, slower, veryslow), все равно будет очень много данных.
По поводу Третье место: «Неуловимое исключение». Всегда был уверен, что любые ошибки приватного наследования обнаруживаются на стадии компиляции. А тут такое. Проверил в MSVS. Если поставить в конце catch(…), то catch(std::exception&) молча пропускается, перехват в catch(…). Если убрать catch(…), то в debug возникает abort, в releast ничего. Стало быть полная статическая типизация при перехвате исключения невозможна. Очень полезная информация.
Для меня метки времени одна из самых таинственных частей ffmpeg. То, что я написал базируется на экспериментах, в сомнительных случаях я просто тупо вывожу метки в лог.
Stream #0:0: Video: h264 (High), yuv420p(progressive), 3840x2160 [SAR 1:1 DAR 16:9], 30.30 fps, 29.97 tbr, 1k tbn, 59.94 tbc (default)
ffmpeg -c:v h264_qsv -i INPUT -f null — -benchmark
на выходе
frame= 2241 fps=129 q=-0.0 Lsize=N/A time=00:01:14.77 bitrate=N/A speed=4.3x
Загрузка ЦП — 35%, графический процессор — 80%