Звучит заманчиво, самому бы хотелось решения с помощью подобного варианта, но возникают вопросы. Допустим у нас компилятор с помощью опций или директив поддерживает старую и новую версию С++. Мы можем писать код полностью на новой версии или на старой версии - ура! Но если мы хотим поддерживать несколько версий одновременно, значит мы планируем какой-то постепенный переход. А как в этой ситуации делать interop ? ABI сломано, одни и те же конструкции теперь могут означать совсем разное. Через "С" ?
В своё время тоже плотно возился с DirectX и GDI. Эх как давно было! Если вы хотите просто вывести свой DIB, но не хотите что бы GDI отслеживал его как ресурс, лучше использовать функцию SetDIBitsToDevice, сэкономите целое копирование. В 2001-м году, такие нюансы были ой как заметны и важны ;)
У меня корейское FALTO Expert Star 2.5 года. Ничего не сломалось, не поцарапалось, не провисло. Все регулировки, которые мне нужны есть, в том числе регулировка сидения по глубине, жесткость качки назад и фиксация при откидывании при любом положении. Кевларовая сетка, не провисла не промялась. У подлокотников 4-ре разные регулировки. Из звуков, только щелчки в крайних положениях. Мыть да, не все места удобно, по-этому подразбирал недавно для генеральной уборки, смазка вся на месте. Еще удобно, что колёсики прорезинены. Они не стирают ламинат и кресло не откатывается само по себе. Считаю, что за свои деньги, лучшее кресло. Недостатков пока не обнаружено.
Константы вообще (const - абстрактно) и константы времени компиляции различаются компилятором. Константы времени компиляции - это буквально значения, которые могут быть определены прямо во время компиляции (не линковки).
std::launder используется в библиотечном коде, когда нужно уплотнится и переиспользовать память, в каком-нибудь std::variant или другом типе-сумме. std::launder - внутри использует компиляторозависимую директиву. Не представляю как это можно написать самому.
Без std::as_const можно обойтись, но нужно будет писать свою. А зачем если стандартная есть ?! Используется в основном в дебрях шаблонов в обобщенном коде, где имя типа может быть очень длинным.
Если вы не писали такой сложный библиотечный код, то вам это действительно не нужно.
Нет. Это потому, что именно функция с std::expected и типы подобраны так, что компилятор всё умудрился вычислить на этапе компиляции. Использование исключения в функции автоматически включает runtime и функция будет вызываться явно (также для такой функции невозможно указать constexpr). Правда это не отменяет того факта, что тест сделан некорректно, т.к. на практике количество ситуаций, где все-все входные данные известны на этапе компиляции, весьма ограничено.
Спасибо! Конечно shaka и hls мы смотрели и использовали в первую очередь, поэтому и спрашивал, может быть появилось что-то новое более надежное. Shaka и hls при беглом осмотре вроде как работают, если играть короткие клипы или фильмы длиною до 3-х часов. При детальном осмотре и там и там масса проблем, например: - периодические зависания при проигрывании по непонятным причинам (дна библиотека может играть один манифест, но подвисать при проигрывании другого и наоборот, обе в разных местах) - подвисают на некоторых Gap-ах в потоке (хотя по документации и в соответствии с настройками они должны пропускаться) - неправильно работает позиционирование на очень длинных по времени таймлайнах (больше 20 часов и выше)
Связывались с разработчиками, высылали bug report-ы. Ошибки подтвердили, но у них там свои роки и приоритеты.
С форматом воде как всё понятно, а не могли бы вы посоветовать плееры которые поддерживают все перечисленные параметры, учитывая популярные сейчас браузеры и устройства?
На сколько я понял, номер шарда у них, это аналог версии баннера, а дальше делается просто CAS или Test And Set, как у многих атомарных операций - параллельно два обработчика меняют данные одно и того же баннера, но закоммитить изменения сможет только один из них, т.к. коммит выполнится только при условии, что версия баннера в базе совпадает с ожидаемой. Второй же обработчик увидит новый номер версии, проставленный первым, транзакция не пройдет и ему придется заново читать изменения из базы и снова пытаться повторить свои изменения.
Ах если бы всё было так просто и можно было весь пайп-лайн прибить гвоздями. На практике, иногда нет аппаратного декодера или энкодера. Конфигурация определяется динамически и код обязан работать корректно. Аппаратура не совершенна и многие карты захвата не могут класть данные напрямую в GPU. Даже если энкодер аппаратный, нам приходится приходится правильно передавать данные из CPU в GPU.
Тема действительно интересная, обширная и сложная. Если брать изображения вообще в общем, как буфер кадра который может прийти откуда угодно, с любой аппаратной части, находится в разного типа памяти, то например в ffmpeg или библиотеках обработки видео и изображений всё становиться еще сложнее. Там у буфера кадра одновременно присутствует и align, и такие понятия как pitch и stride, причем все они могут иметь разные значения в общем случае: align - это выравнивание начала строки в байтах. Необходимо для того, что бы строка могла быть обработана SIMD инструкциями, которые требуют выравнивания. pitch - это выравнивания в пикселах (может быть горизонтальным и вертикальным). Необходимо тем или иным алгоритмам, которые работают блоками, например кодеки или специфические фильтры. stride - это выравнивание строки в байтах. Необходимо как для работы SIMD, так и для менеджера памяти, который используется для хранения изображения (например в видеопамяти). Также в зависимости от формата изображения могут иметь так называемые плоскости (цветовые компоненты), которые хранятся отдельно друг от друга и имеют собственные выравнивания. На практике всё это может быть не кратно друг другу, а каждый кодек имеет свои значения. В своё время пришлось плотно разбираться с этим и разрабатывать хитрые обертки, что бы сделать прозрачную передачу (без копирования): кадр из оперативной памяти -> медиа семпл DirectShow -> ffmpeg кадр -> медиа семпл DirectShow -> кадр в оперативной памяти
Да, тоже становится грустно, почему люди не проверяют факты, которые сами же вскользь и указывают: Wolf 3D - ray casting и DDA, ускорение относительно честного 3D происходит из-за того, что все расчеты происходят на 2-мерной карте, разделённой на прямоугольные блоки одинакового размера. Стены могут быть только кратны определённой сетке и вертикальными. Duke Nukem 3D - portals, ускорение относительно честного 3D происходит за счет того, что отсечение происходит на 2-х мерной карте пошагово, от ближнего портала (выпуклое множество полигонов), потом следующие порталы, те, что потенциально могут быть видны из текущего и т.д. В отличие от BSP, все расчеты происходят в реальном времени, соответственно карта игры большими частями может меняться динамически. Doom - BSP, ускорение относительно честного 3D происходит за счет того, что стационарные стены рисуются по порядку, от ближних к дальним по специальному дереву, опять же на 2-мерной карте. Стены также строго вертикальные, но уже под любым углом по оставшимся плоскостям. Quake - честный 3D, но стационарные стены рисуются по 3-х мерному BSP на 3-х мерной карте. Отсюда ограничения, большая часть мира - статическая, т.к. BSP очень дорого рассчитывать в динамике.
Итого, из основных родоначальников жанра, только Wolf 3D использует ray casting.
в UTF-16 кодовая точка всегда использует 2 байта (16 бит)
И тут же противоречие:
Но максимальным значение 16-битного числа является 65535! Как представляются большие числа в UTF-16? Для этого используется концепция суррогатной пары (surrogate pair)
Вывод: В UTF-16 кодовая точка, также как и в UTF-8, занимает максимум 4 байта.
Моё замечание относится к тому, что хотя в общем идея чисел с плавающей точкой объяснена, только вот в IEEE-754 экспонента (e) - это показатель степени по основанию 2, а не по основанию 10, как в статье. Т.е. не 10^e, а 2^e.
Мне кажется, что в современном С++ это можно сделать на уровне библиотеки и работать с такими числами почти как с встроенными. Вот моя попытка написать такое для целых - Simple long integer math library for C++. Посмотрите, может подойдет. Из того, что вам нужно, там нет точности до бита и динамического изменения размера, так как я пока не знаю как выполнить эти требования и при этом быть сравнимым по эффективности с встроенными типами.
constexpr auto uo = 03766713523035452062041773345651416625031020_ui128; // octal unsigned integer
constexpr auto ud = 338770000845734292534325025077361652240_ui128; // decimal unsigned integer
constexpr auto uh = 0xfedcba9876543210fedcba9876543210_ui128; // hexadecimal unsigned integer
constexpr auto io = -03766713523035452062041773345651416625031020_si128; // octal signed integer
constexpr auto id = -338770000845734292534325025077361652240_si128; // decimal signed integer
constexpr auto ih = -0xfedcba9876543210fedcba9876543210_si128; // hexadecimal signed integer
constexpr auto u = 0xfedcba98'76543210'fedcba98'76543210_ui128; // hexadecimal unsigned integer
Звучит заманчиво, самому бы хотелось решения с помощью подобного варианта, но возникают вопросы. Допустим у нас компилятор с помощью опций или директив поддерживает старую и новую версию С++. Мы можем писать код полностью на новой версии или на старой версии - ура! Но если мы хотим поддерживать несколько версий одновременно, значит мы планируем какой-то постепенный переход. А как в этой ситуации делать interop ? ABI сломано, одни и те же конструкции теперь могут означать совсем разное. Через "С" ?
В своё время тоже плотно возился с DirectX и GDI. Эх как давно было!
Если вы хотите просто вывести свой DIB, но не хотите что бы GDI отслеживал его как ресурс, лучше использовать функцию SetDIBitsToDevice, сэкономите целое копирование. В 2001-м году, такие нюансы были ой как заметны и важны ;)
У меня корейское FALTO Expert Star 2.5 года. Ничего не сломалось, не поцарапалось, не провисло. Все регулировки, которые мне нужны есть, в том числе регулировка сидения по глубине, жесткость качки назад и фиксация при откидывании при любом положении. Кевларовая сетка, не провисла не промялась. У подлокотников 4-ре разные регулировки.
Из звуков, только щелчки в крайних положениях. Мыть да, не все места удобно, по-этому подразбирал недавно для генеральной уборки, смазка вся на месте. Еще удобно, что колёсики прорезинены. Они не стирают ламинат и кресло не откатывается само по себе.
Считаю, что за свои деньги, лучшее кресло. Недостатков пока не обнаружено.
Константы вообще (const - абстрактно) и константы времени компиляции различаются компилятором. Константы времени компиляции - это буквально значения, которые могут быть определены прямо во время компиляции (не линковки).
Грубо говоря, вот такое не сделать:
std::launder используется в библиотечном коде, когда нужно уплотнится и переиспользовать память, в каком-нибудь std::variant или другом типе-сумме. std::launder - внутри использует компиляторозависимую директиву. Не представляю как это можно написать самому.
Без std::as_const можно обойтись, но нужно будет писать свою. А зачем если стандартная есть ?! Используется в основном в дебрях шаблонов в обобщенном коде, где имя типа может быть очень длинным.
Если вы не писали такой сложный библиотечный код, то вам это действительно не нужно.
Только если данный вариант инициализации m_cash по умолчанию уникальный для данного конструктора. Лучше так:
Согласитесь, что могут появиться и другие конструкторы и значения по умолчанию лучше иметь в одном месте.
Нет. Это потому, что именно функция с std::expected и типы подобраны так, что компилятор всё умудрился вычислить на этапе компиляции. Использование исключения в функции автоматически включает runtime и функция будет вызываться явно (также для такой функции невозможно указать constexpr).
Правда это не отменяет того факта, что тест сделан некорректно, т.к. на практике количество ситуаций, где все-все входные данные известны на этапе компиляции, весьма ограничено.
Спасибо! Конечно shaka и hls мы смотрели и использовали в первую очередь, поэтому и спрашивал, может быть появилось что-то новое более надежное.
Shaka и hls при беглом осмотре вроде как работают, если играть короткие клипы или фильмы длиною до 3-х часов. При детальном осмотре и там и там масса проблем, например:
- периодические зависания при проигрывании по непонятным причинам (дна библиотека может играть один манифест, но подвисать при проигрывании другого и наоборот, обе в разных местах)
- подвисают на некоторых Gap-ах в потоке (хотя по документации и в соответствии с настройками они должны пропускаться)
- неправильно работает позиционирование на очень длинных по времени таймлайнах (больше 20 часов и выше)
Связывались с разработчиками, высылали bug report-ы. Ошибки подтвердили, но у них там свои роки и приоритеты.
Я имел в виду Web player конечно. В отрыве от браузера проиграть любой HLS не составляет никакой проблемы.
С форматом воде как всё понятно, а не могли бы вы посоветовать плееры которые поддерживают все перечисленные параметры, учитывая популярные сейчас браузеры и устройства?
На сколько я понял, номер шарда у них, это аналог версии баннера, а дальше делается просто CAS или Test And Set, как у многих атомарных операций - параллельно два обработчика меняют данные одно и того же баннера, но закоммитить изменения сможет только один из них, т.к. коммит выполнится только при условии, что версия баннера в базе совпадает с ожидаемой. Второй же обработчик увидит новый номер версии, проставленный первым, транзакция не пройдет и ему придется заново читать изменения из базы и снова пытаться повторить свои изменения.
Ах если бы всё было так просто и можно было весь пайп-лайн прибить гвоздями. На практике, иногда нет аппаратного декодера или энкодера. Конфигурация определяется динамически и код обязан работать корректно. Аппаратура не совершенна и многие карты захвата не могут класть данные напрямую в GPU. Даже если энкодер аппаратный, нам приходится приходится правильно передавать данные из CPU в GPU.
Тема действительно интересная, обширная и сложная. Если брать изображения вообще в общем, как буфер кадра который может прийти откуда угодно, с любой аппаратной части, находится в разного типа памяти, то например в ffmpeg или библиотеках обработки видео и изображений всё становиться еще сложнее. Там у буфера кадра одновременно присутствует и align, и такие понятия как pitch и stride, причем все они могут иметь разные значения в общем случае:
align - это выравнивание начала строки в байтах. Необходимо для того, что бы строка могла быть обработана SIMD инструкциями, которые требуют выравнивания.
pitch - это выравнивания в пикселах (может быть горизонтальным и вертикальным). Необходимо тем или иным алгоритмам, которые работают блоками, например кодеки или специфические фильтры.
stride - это выравнивание строки в байтах. Необходимо как для работы SIMD, так и для менеджера памяти, который используется для хранения изображения (например в видеопамяти).
Также в зависимости от формата изображения могут иметь так называемые плоскости (цветовые компоненты), которые хранятся отдельно друг от друга и имеют собственные выравнивания. На практике всё это может быть не кратно друг другу, а каждый кодек имеет свои значения. В своё время пришлось плотно разбираться с этим и разрабатывать хитрые обертки, что бы сделать прозрачную передачу (без копирования):
кадр из оперативной памяти -> медиа семпл DirectShow -> ffmpeg кадр -> медиа семпл DirectShow -> кадр в оперативной памяти
Да, тоже становится грустно, почему люди не проверяют факты, которые сами же вскользь и указывают:
Wolf 3D - ray casting и DDA, ускорение относительно честного 3D происходит из-за того, что все расчеты происходят на 2-мерной карте, разделённой на прямоугольные блоки одинакового размера. Стены могут быть только кратны определённой сетке и вертикальными.
Duke Nukem 3D - portals, ускорение относительно честного 3D происходит за счет того, что отсечение происходит на 2-х мерной карте пошагово, от ближнего портала (выпуклое множество полигонов), потом следующие порталы, те, что потенциально могут быть видны из текущего и т.д. В отличие от BSP, все расчеты происходят в реальном времени, соответственно карта игры большими частями может меняться динамически.
Doom - BSP, ускорение относительно честного 3D происходит за счет того, что стационарные стены рисуются по порядку, от ближних к дальним по специальному дереву, опять же на 2-мерной карте. Стены также строго вертикальные, но уже под любым углом по оставшимся плоскостям.
Quake - честный 3D, но стационарные стены рисуются по 3-х мерному BSP на 3-х мерной карте. Отсюда ограничения, большая часть мира - статическая, т.к. BSP очень дорого рассчитывать в динамике.
Итого, из основных родоначальников жанра, только Wolf 3D использует ray casting.
Цитата:
И тут же противоречие:
Вывод: В UTF-16 кодовая точка, также как и в UTF-8, занимает максимум 4 байта.
Моё замечание относится к тому, что хотя в общем идея чисел с плавающей точкой объяснена, только вот в IEEE-754 экспонента (e) - это показатель степени по основанию 2, а не по основанию 10, как в статье. Т.е. не 10^e, а 2^e.
10 - или я не понял вопроса ?!
Всё хорошо в объяснении, только вот экспонента (порядок) это степень двойки, а не десятки. Неплохо бы было объяснить и это момент.
Мне кажется, что в современном С++ это можно сделать на уровне библиотеки и работать с такими числами почти как с встроенными. Вот моя попытка написать такое для целых - Simple long integer math library for C++. Посмотрите, может подойдет.
Из того, что вам нужно, там нет точности до бита и динамического изменения размера, так как я пока не знаю как выполнить эти требования и при этом быть сравнимым по эффективности с встроенными типами.
Так ведь _pascal calling conversion давно уже устарело и не рекомендуется к использованию. Это смотря где определение.
https://learn.microsoft.com/en-us/cpp/cpp/obsolete-calling-conventions?view=msvc-170
В общем это всё дела уже минувших дней и неактуально сегодня.