int является тривиальным типом, поэтому при выполнении new int[42] для элементов не будет вызван конструктор по умолчанию (который для int просто обнуляет) и вектор будет инициализирован случайными значениями. Для не тривиальных типов гарантирован вызов конструктора по умолчанию. Два других варианта как раз и гарантируют вызов конструктора по умолчанию для любых типов, в том числе и тривиальных и в приведенных примерах вектор будет обнулен. Вариант с фигурными скобками позволяет задать произвольные инициализирующие значения для элементов вектора.
Согласен, что кастомные аллокаторы вещь довольно редкая. Аллокаторы для стандартных контейнеров тема весьма обширная, требует отдельной статьи. Именно там уместно обсудить pmr. На первый взгляд pmr ничего особенного из себя не представляют, достаточно традиционная кастомизация аллокатора с помощью виртуальных функция. Небольшие дополнительные накладные расходы на вызов виртуальных функций и за это полное отделения интерфейса от реализации. Я пока эту тему глубоко не копал, может там действительно есть что-то интересное.
Конечно получится плохо. Вообще using-директива в заголовочном файле относится к запрещенным приемам. Описанная возможность носит скорее абстрактный характер, служит для лучшего понимания архитектуры стандартной библиотеки и каких-то экспериментов. Лично я вообще никогда не использую using-директиву (правда, никогда не говори никогда). Так, что надо не поленится и ручками определить все операторы.
В контейнерах и алгоритмах, использующих 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), все равно будет очень много данных.
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%