Если начинающие программисты будут думать что массивы в C++ это std::array и std::vector, а T[] это такая штука из далекого прошлого примерно как register или std::auto_ptr, то всем будет только лучше.
FFmpeg тоже нельзя. Либо вы не замечаете погрешности, либо граница удачно попадает на опорный кадр.
Проблема в том, что практически в любом видео для декодирования кадра нужен как минимум предыдущий опорный кадр, а в некоторых случаях еще и следующий. Чтобы и включить нужные кадры в файл, и при этом не воспроизводить лишние, нужна возможность в файле оставить пометки сколько видео надо пропустить в начале и конце.
Причем такая функциональность должна поддерживаться форматом файла-контейнера, FFmpeg, большинством плееров и пр. Последний раз когда я пытался копировать отрезки из видео где-то лет пять назад, я ничего похожего не нашел.
Начало, а в некоторых случаях даже конец видеоряда нельзя обрезать в произвольном месте, так что Handbrake скорее всего реализовали более общий случай и не стали заморачиваться с частными.
для кодировщиков на базе QSV (Intel Quick Sync Video) метод управления битретом по умолчанию изменён с VBR (переменный битрейт) на CQP (постоянный битрейт)
CQP это постоянное качество (Constant Quantization Parameter), в зависимости от кодируемого видео это может ещё более переменный битрейт, чем VBR.
Проблема с наименованием тут в том, что логика прослеживается если знать историю появления этих типов и особенности принятия решений комитетом. Без этого контекста набор из этих трех типов выглядит как WTF.
Помимо SSO, там еще есть поддержка специализаций const/&/&&. В целом std::copyable_function -- это исправленный std::function. В определенной мере было бы даже логичнее назвать новый тип std::function2 и не морочить людям голову.
Или как минимум сразу же задепрекейтить старый std::function, но судя по std::thread и std::jthread этого не будет.
То, что он пока еще непринятый -- это софистика. std::jthread приняли, оставив std::thread как есть, и этот примут.
Если бы были только типы std::copyable_function и std::move_only_function, то все было бы в порядке. Но получается так, что в стандартной библиотеке на равных правах сосуществуют три типа:
std::function
std::copyable_function
std::move_only_function
И вот тут уже названия становятся понятными только тем, кто знает историю их появления и/или ход мыслей комитета.
в отличие от С++, где shared ptr передаёт семантику, в расте название это аббревиатура от реализации
После того, как в C++ получилось, что между std::function и std::copyable_function разница совсем не в том, что один тип копируемый, а другой -- нет, я как-то перестал пинать другие языки за неочевидные наименования.
Это удобно, когда в shared_ptr заворачивается какой-то посторонний ресурс: указатель из мира C, хендлер со своей логикой, токен какой-нибудь который надо вернуть в пул и т. п.
Можно сделать обертку с необходимым действием в деструкторе, но это нудно и неудобно по очевидным причинам. Или можно просто при оборачивании ресурса в умный указатель лаконично указать что надо сделать, когда указатель все.
Этот комментарий и ещё один выше от того же автора как будто сгенерированы нейросетью, которой дали задание написать оправдание/объяснение почему нейросеть может не справиться с задачей.
Проблемы с контекстом: В задаче описывается определенный контекст, включая цвета, национальности, питомцев, напитки и курение.
Совершенно очевидно, что все эти цвета и национальности не играют никакой роли и добавлены просто чтобы человеку было проще запомнить условия.
Логические задачи могут быть подвержены различным толкованиям и иметь несколько верных решений. <...> Однако, ваше видение и интерпретация задачи являются допустимыми и могут привести к другому верному ответу. Это связано с тем, что некоторые аспекты условий задачи могут быть неоднозначны или подвержены субъективному толкованию.
В данной задаче нет неоднозначностей и возможности различного и уж тем более субъективного толкования.
Ну и в целом текст написан в стиле, характерном для ИИ.
Если скорость копирования с фотоаппарата на комп действительно не так уж важна, то незачем даже вынимать карточку, большинство фотоаппаратов можно подключить к компу по USB и копировать файлы напрямую.
в андроиде есть графика, андроид открыт, почему не использовать их решение для графики, зачем wayland?
Графический стек андроида сильно привязан к самому андроиду и его сценариям использования. Wayland это более общее решение для более широкого круга задач.
Вот не надо пытаться "поддерживать темы и стилизацию конкретного DE". <...> Ну а общий стиль декораций - это именно атавизм <...> одинаковые они не потому, что кто-то так захотел, а потому что декоратору проще рисовать всегда одинаково
Не надо пытаться делать общий стиль вообще, пусть все приложения выглядят как попало?
Единое оформление и поведение окон это атавизм, который ну просто так случайно получился?
Что за чушь Вы несете?
декорации окна под голым вейландом делаются примерно настолько же просто как и обычная кнопка <...> проблем у бестулкитных программ в мире CSD вообще нет
Ага, щас. Декорации это не только простенькие линии на границе окна, это еще и заголовок, кнопочки управления окном в заголовке и вся логика управления размерами окна от переразмерения мышью до всяких двойных кликов для разворачивания на весь экран и т. п.
Без прямой или косвенной помощи DE приложение будет и выглядеть, и вести себя как черти-что, полностью выбиваясь из общего стиля и логики работы остального рабочего стола. Я даже не знаю насколько пофиг должно быть на всех и вся, чтобы считать что это допустимый вариант.
И SSD эту проблему не решает вообще никак, даже частично.
SSD решает эту проблему целиком и полностью. Просто по построению.
если разработчик "ожидает по умолчанию" - это проблема разработчика, он, видимо, не до конца понимает, под какую среду он пишет
Да прекрасно все мы понимаем, под Gnome. Ни в каком другом случае этот вопрос даже не поднимался бы. Только в Gnome ожидания пользователя (в данном случае пользователя API) это проблемы пользователя, и вообще это вам не надо, а надо сплясать вприсядку и подставить костылей чтобы в итоге все равно получить точно то же самое, потому что иначе никак.
Это если в обязательном порядке есть тулкит, в котором есть поддержка тем и нюансов стилизации конкретного DE.
Во-первых, приложению может быть и не нужен тулкит, если у него нет обычного UI. Когда началась эта катавасия с CSD в Gnome, отвалилось оформление целой кучи разных приложений: игры, плееры, терминалы. Часть потом полечили поддержкой libdecor в SDL, но это не исправляет суть проблемы. Зачем приложению тажеленная зависимость от тулкита, если оно им не собирается пользоваться?
Во-вторых, мир опять-таки не ограничивается GTK и Qt. Формально, в Linux может быть неограниченное количество самых разных тулкитов для самых разных целей, и все они должны поддерживать возможные закидоны всех мыслимых DE?
Общие декорации это не атавизм, а то, что ожидает разработчик приложения по умолчанию. В подавляющем большинстве случаев они предоставляются тулкитом, но вариант создания окна напрямую через X или Wayland ничем по смыслу не отличается от создания окна напрямую через WinAPI или Cocoa. Если бы у Linux был бы один официальный и всегда без вариантов доступный тулкит для UI, задачу декораций можно было бы переложить на него, как в случае с Windows или macOS. Но в Linux в качестве такого "тулкита" выступают X и Wayland.
Нормальные же люди будут юзать экраны с нормальным DPI
Я купил 4K монитор только потому, что устал смотреть на пикселявый текст. Поставил на 4K масштаб 200%, все по размерам осталось как и было, только текст теперь нормальный.
Да, на моменте с CSD я тоже понял что добром это не кончится.
Wayland не требует от композитора поддержки SSD, клиент все равно обязан быть готовым предоставить CSD, а еще нам лень, так что давайте все реализуйте CSD.
И ведь главное находятся защищающие эту позицию. Мол раз Wayland не требует, значит можно, нет, даже не так, это правильно не поддерживать SSD. То, что причина опциональности SSD (наличие сценариев, когда SSD не имеет смысла, например телефон или киоск) не имеет никакого отношения к десктопам, никого не интересует.
Как приложение должно узнать о дизайне декораций конкретного Gnome и реализовать их в соответствии со всеми системными настройками, в точности так же, как и все остальные приложения -- тоже очень мало кого интересует. Используй GTK, что ты как маленький.
По какой-то непонятной причине мир GTK не ограничивается. Но поскольку предоставлять декорации по запросу клиента мы не хотим, сделаем специальную библиотеку libdecor, которая по запросу клиента предоставит декорации. Теперь любое приложение, которое не использует популярный UI-фреймворк, должно таскать с собой этот костыль для Gnome.
Для smart ptr нужны деструкторы. Их нет в стандарте
Деструкторы, которые вы имеете в виду, нужны для RAII.
Для умных указателей формально они не нужны. FFmpeg полон использования shared ptr для управления ресурсами, GLib предоставляет функциональность shared/weak ptr и наверняка ещё куча, если не большинство сложных проектов на C так или иначе приходят к использованию подсчёта ссылок с финализацией объекта.
Для option/either/maybe нужны дженерики. Си может предложить только макросы
В виде какой-нибудь стандартной библиотеки реализовать их и вышеупомянутые умные указатели непросто.
Но в пределах одного проекта вполне возможно. Конкретизируя каждый тип и/или необходимые для него методы (av_frame_ref, ns_optional_type1, ns_either_type2_type3 и т. д.) либо вручную, либо при помощи макроса.
Если начинающие программисты будут думать что массивы в C++ это std::array и std::vector, а T[] это такая штука из далекого прошлого примерно как register или std::auto_ptr, то всем будет только лучше.
FFmpeg тоже нельзя. Либо вы не замечаете погрешности, либо граница удачно попадает на опорный кадр.
Проблема в том, что практически в любом видео для декодирования кадра нужен как минимум предыдущий опорный кадр, а в некоторых случаях еще и следующий. Чтобы и включить нужные кадры в файл, и при этом не воспроизводить лишние, нужна возможность в файле оставить пометки сколько видео надо пропустить в начале и конце.
Причем такая функциональность должна поддерживаться форматом файла-контейнера, FFmpeg, большинством плееров и пр. Последний раз когда я пытался копировать отрезки из видео где-то лет пять назад, я ничего похожего не нашел.
Начало, а в некоторых случаях даже конец видеоряда нельзя обрезать в произвольном месте, так что Handbrake скорее всего реализовали более общий случай и не стали заморачиваться с частными.
CQP это постоянное качество (Constant Quantization Parameter), в зависимости от кодируемого видео это может ещё более переменный битрейт, чем VBR.
Проблема с наименованием тут в том, что логика прослеживается если знать историю появления этих типов и особенности принятия решений комитетом. Без этого контекста набор из этих трех типов выглядит как WTF.
Помимо SSO, там еще есть поддержка специализаций const/&/&&. В целом
std::copyable_function-- это исправленныйstd::function. В определенной мере было бы даже логичнее назвать новый типstd::function2и не морочить людям голову.Или как минимум сразу же задепрекейтить старый
std::function, но судя поstd::threadиstd::jthreadэтого не будет.То, что он пока еще непринятый -- это софистика.
std::jthreadприняли, оставивstd::threadкак есть, и этот примут.Если бы были только типы
std::copyable_functionиstd::move_only_function, то все было бы в порядке. Но получается так, что в стандартной библиотеке на равных правах сосуществуют три типа:std::functionstd::copyable_functionstd::move_only_functionИ вот тут уже названия становятся понятными только тем, кто знает историю их появления и/или ход мыслей комитета.
Что, думаете одумаются и таки назовут
std::function2?Ничего не знаю, у нас в 2026 все есть.
После того, как в C++ получилось, что между
std::functionиstd::copyable_functionразница совсем не в том, что один тип копируемый, а другой -- нет, я как-то перестал пинать другие языки за неочевидные наименования.Это удобно, когда в shared_ptr заворачивается какой-то посторонний ресурс: указатель из мира C, хендлер со своей логикой, токен какой-нибудь который надо вернуть в пул и т. п.
Можно сделать обертку с необходимым действием в деструкторе, но это нудно и неудобно по очевидным причинам. Или можно просто при оборачивании ресурса в умный указатель лаконично указать что надо сделать, когда указатель все.
Этот комментарий и ещё один выше от того же автора как будто сгенерированы нейросетью, которой дали задание написать оправдание/объяснение почему нейросеть может не справиться с задачей.
Совершенно очевидно, что все эти цвета и национальности не играют никакой роли и добавлены просто чтобы человеку было проще запомнить условия.
В данной задаче нет неоднозначностей и возможности различного и уж тем более субъективного толкования.
Ну и в целом текст написан в стиле, характерном для ИИ.
Если скорость копирования с фотоаппарата на комп действительно не так уж важна, то незачем даже вынимать карточку, большинство фотоаппаратов можно подключить к компу по USB и копировать файлы напрямую.
Графический стек андроида сильно привязан к самому андроиду и его сценариям использования. Wayland это более общее решение для более широкого круга задач.
Учитывая что почти все сейчас рисуется GPU, проброс X в общем виде деградирует до RDP/VNC.
Я вообще не понимаю о чем Вы.
Не надо пытаться делать общий стиль вообще, пусть все приложения выглядят как попало?
Единое оформление и поведение окон это атавизм, который ну просто так случайно получился?
Что за чушь Вы несете?
Ага, щас. Декорации это не только простенькие линии на границе окна, это еще и заголовок, кнопочки управления окном в заголовке и вся логика управления размерами окна от переразмерения мышью до всяких двойных кликов для разворачивания на весь экран и т. п.
Без прямой или косвенной помощи DE приложение будет и выглядеть, и вести себя как черти-что, полностью выбиваясь из общего стиля и логики работы остального рабочего стола. Я даже не знаю насколько пофиг должно быть на всех и вся, чтобы считать что это допустимый вариант.
SSD решает эту проблему целиком и полностью. Просто по построению.
Да прекрасно все мы понимаем, под Gnome. Ни в каком другом случае этот вопрос даже не поднимался бы. Только в Gnome ожидания пользователя (в данном случае пользователя API) это проблемы пользователя, и вообще это вам не надо, а надо сплясать вприсядку и подставить костылей чтобы в итоге все равно получить точно то же самое, потому что иначе никак.
Это если в обязательном порядке есть тулкит, в котором есть поддержка тем и нюансов стилизации конкретного DE.
Во-первых, приложению может быть и не нужен тулкит, если у него нет обычного UI. Когда началась эта катавасия с CSD в Gnome, отвалилось оформление целой кучи разных приложений: игры, плееры, терминалы. Часть потом полечили поддержкой libdecor в SDL, но это не исправляет суть проблемы. Зачем приложению тажеленная зависимость от тулкита, если оно им не собирается пользоваться?
Во-вторых, мир опять-таки не ограничивается GTK и Qt. Формально, в Linux может быть неограниченное количество самых разных тулкитов для самых разных целей, и все они должны поддерживать возможные закидоны всех мыслимых DE?
Общие декорации это не атавизм, а то, что ожидает разработчик приложения по умолчанию. В подавляющем большинстве случаев они предоставляются тулкитом, но вариант создания окна напрямую через X или Wayland ничем по смыслу не отличается от создания окна напрямую через WinAPI или Cocoa. Если бы у Linux был бы один официальный и всегда без вариантов доступный тулкит для UI, задачу декораций можно было бы переложить на него, как в случае с Windows или macOS. Но в Linux в качестве такого "тулкита" выступают X и Wayland.
Я купил 4K монитор только потому, что устал смотреть на пикселявый текст. Поставил на 4K масштаб 200%, все по размерам осталось как и было, только текст теперь нормальный.
4k в 90 DPI это 3840 / 90 = 42.7 дюйма или 107 см по ширине. Либо у вас монитор с диагональю 48", либо все-таки масштаб 200% =).
Да, на моменте с CSD я тоже понял что добром это не кончится.
Wayland не требует от композитора поддержки SSD, клиент все равно обязан быть готовым предоставить CSD, а еще нам лень, так что давайте все реализуйте CSD.
И ведь главное находятся защищающие эту позицию. Мол раз Wayland не требует, значит можно, нет, даже не так, это правильно не поддерживать SSD. То, что причина опциональности SSD (наличие сценариев, когда SSD не имеет смысла, например телефон или киоск) не имеет никакого отношения к десктопам, никого не интересует.
Как приложение должно узнать о дизайне декораций конкретного Gnome и реализовать их в соответствии со всеми системными настройками, в точности так же, как и все остальные приложения -- тоже очень мало кого интересует. Используй GTK, что ты как маленький.
По какой-то непонятной причине мир GTK не ограничивается. Но поскольку предоставлять декорации по запросу клиента мы не хотим, сделаем специальную библиотеку libdecor, которая по запросу клиента предоставит декорации. Теперь любое приложение, которое не использует популярный UI-фреймворк, должно таскать с собой этот костыль для Gnome.
Деструкторы, которые вы имеете в виду, нужны для RAII.
Для умных указателей формально они не нужны. FFmpeg полон использования shared ptr для управления ресурсами, GLib предоставляет функциональность shared/weak ptr и наверняка ещё куча, если не большинство сложных проектов на C так или иначе приходят к использованию подсчёта ссылок с финализацией объекта.
В виде какой-нибудь стандартной библиотеки реализовать их и вышеупомянутые умные указатели непросто.
Но в пределах одного проекта вполне возможно. Конкретизируя каждый тип и/или необходимые для него методы (av_frame_ref, ns_optional_type1, ns_either_type2_type3 и т. д.) либо вручную, либо при помощи макроса.