Никаких гарантий ни на что, в том числе и что вы не забудете добавить новое поле в список инициализации или что вызывающий код не аллоцирует "объект" через malloc().
Если вам кажется, что в вашем случае нужно конструктор, то пишите конструктор. Но при использовании небольшой структуры фигурные скобки достаточная гарантия, что конкретно с этим объектом в отладчике развлекаться не придется.
Я конкретно этот момент и прокомментировал -- нет, если в агрегате лежат не только объекты, но и простые типы, T{} все равно отработкет как и задумано.
К слову, контейнеры стандартной библиотеки тоже выполняют value initialization, так что и за вызывающий код в виде std::vector или std::map можно не переживать.
Пластины винчестера вращаются независимо от того, перезаписывается он, просто читается или вовсе бездействует (если бездействует долго, то можно остановить, но это отдельная история со своими нюансами).
Так что как минимум подшипникам все равно как часто будут перезаписаны данные.
The first time you build and run the project this way, it will download a prebuilt shared library for the Dawn native WebGPU implementation automatically <...> Optionally, Dawn can be built from scratch with gpu.cpp <...> However, this is recommended for advanced users only. Building Dawn dependencies with cmake takes much longer than using the precompiled Dawn shared library.
В наше-то время предлагать выполнять автоматически скачиваемый неизвестно откуда бинарник >___<.
Если начинающие программисты будут думать что массивы в 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 и копировать файлы напрямую.
Никаких гарантий ни на что, в том числе и что вы не забудете добавить новое поле в список инициализации или что вызывающий код не аллоцирует "объект" через malloc().
Если вам кажется, что в вашем случае нужно конструктор, то пишите конструктор. Но при использовании небольшой структуры фигурные скобки достаточная гарантия, что конкретно с этим объектом в отладчике развлекаться не придется.
Я конкретно этот момент и прокомментировал -- нет, если в агрегате лежат не только объекты, но и простые типы, T{} все равно отработкет как и задумано.
К слову, контейнеры стандартной библиотеки тоже выполняют value initialization, так что и за вызывающий код в виде std::vector или std::map можно не переживать.
T foo{}; гарантированно зануляет простые типы.
Вот если вы наоборот добавите конструктор, но не упомянете в нем эти поля -- тогда да, они не будут инициализированы.
Грамматика более простая и строгая, легче парсить и анализировать.
Пластины винчестера вращаются независимо от того, перезаписывается он, просто читается или вовсе бездействует (если бездействует долго, то можно остановить, но это отдельная история со своими нюансами).
Так что как минимум подшипникам все равно как часто будут перезаписаны данные.
В наше-то время предлагать выполнять автоматически скачиваемый неизвестно откуда бинарник >___<.
Если решать недостаток новых рабочих рук исключительно автоматизацией, можно пройти точку невозврата в отдельно взятом социуме.
Одна фабрика на всю планету это как минимум ненадёжно.
Есть карты с шестизначным пином =).
Если начинающие программисты будут думать что массивы в 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 и копировать файлы напрямую.