Клавиатурные нерды проигнорировали клавишу insert при наличии достаточного места, чтобы ее разместить. На моих Vortex RACE 3 такая же ситуация, и это пожалуй единственный их недостаток.
Можно в качестве имен файлов использовать хеш от видеофайла и таким образом их сопоставлять. Хотя конечно считать хеши многогигабайтных видео не особо шустрая операция.
Я конечно далеко не эксперт в разных языках и парадигмах программирования, но тем не менее с этим утверждением я не согласен. Предусловия бывают самые разные, явные и неявные (подразумевающиеся). Как вы проверите, что вам передали указатель на последовательность символов, оканчивающуюся нулем? Если вызывающий код забудет дописать терминирующий ноль, вы этот факт никак не установите. Как вы проверите, что переданный в функцию указатель на структуру действительно указывает на такую структуру? Rust может гарантировать нечто подобное, но если данные пришли из внешнего источника их все равно придется валидировать. Любой самый защищенный язык при работе с низкоуровневыми абстракциями будет вынужден использовать unsafe секции кода. И там будут непроверяемые или сложнопроверяемые предусловия.
Пример с std::optional просто фееричен по уровню идиотизма. Тип optional и не предоставляет гарантии, что он всегда содержит какое-то значение. На это даже намекает само название типа. Претензии к операторам * и -> только показывают, что автор понятия не имеет о контрактах функций. Если мы посмотрим описание этих операторов на cppreference, то мы увидим, что
The behavior is undefined if *this does not contain a value.
Разработчик обязан удовлетворить предусловия функции перед ее вызовом. В данном случае он обязан убедиться, что optional содержит значение, иначе получит неопределенное поведение. Как бы того ни хотел автор, но в любом языке программирования функции будут иметь предусловия, явные или неявные. Не все предусловия можно проверить. Не все проверки предусловий осуществимы за разумное время. Не все осуществимые проверки стоят того, чтобы быть выполненными. Сомневающихся прошу ознакомиться с данным документом. Всегда придется искать какой-то разумный компромисс. Язык C++ нацелен на максимальную производительность, поэтому написанные на нем библиотеки часто перекладывают на пользователя выполнение дополнительных проверок.
Хотя я не отрицаю, что современный C++ превратился в какого-то монстра и использовать его корректно очень и очень сложно, чтобы бросаться переносить существующие наработки, надо сначала создать хорошую замену C++. Языки с VM и сборщиком мусора не являются заменой по определению. Rust выглядит довольно перспективно, но тоже не без проблем.
Это же обычный вопрос сохранения обратной совместимости при внесении изменений. В один момент Microsoft ввели возможность установить DPI awareness для процесса. Почему бы при рассчете размера шрифта, заданного в пунктах, не начать учитывать DPI экрана в DPI aware приложениях?
Просто нужно разработчикам операционных систем перестать страдать фигней и использовать PPI монитора. То, что есть сейчас, со всеми этими 72/96 PPI, какие-то лютые кривые костыли.
Сейчас в IDEA можно выбирать конкретные code chunks, которые попадут в коммит, но нельзя разбить один code chunk на более мелкие части. Бывает нужно добавить только пару строк из code chunk или все строки кроме одной.
Единственная вещь, которой там для меня нехватает — это возможность добавлять в коммит только указанные строчки. Такая функция есть уже в большинстве графичиских оберток над git. Issue висит уже в их багтрекере годы и имеет кучу апвотов, но пока никакой информации от разработчиков из команды JetBrains. По видимому считают фичу низкоприоритетной, а жаль.
У вас отличный браузер со множеством интересных и уникальных возможностей, но лично я не могу им пользоваться по, казалось бы, довольно пустяковой причине. Абсолютно все программы, имеющие в своей основе Chromium, рендерят бледный текст. В элементах GUI шрифты вообще выглядят смазанно. При чем ситуацию с бледностью можно исправить, собрав Skia c отключенной гамма-коррекцией, только никто этого не делает. Возможно я вообще единственный, кому это не нравится.
Справедливости ради хочу заметить, что в моём конкретном случае проблема перестала проявляться после выхода BIOS с AGESA 1.1.0.0 D несколько месяцев назад. Видимо там что-то сильно нетривиальное, раз эту проблему не смогли обнаружить до поступления в продажу кучи материнок, а потом так долго не могли поправить.
Вспомнилась надпись на парте в школе: «Счастье, это не когда тебе хорошо, а когда другому плохо». Видимо чем-то подобным вдохновляются.
А вообще, что они хотят? Они же замедлили твиттер, вот и реакцию теперь надо дольше ждать.
40-50 минутное видео в FHD пожатое H264 имеет объём около 2.5ГБ. Качается за 3 минуты на 100Mbps. Сейчас уже у многих домшний канал в 300 или 500Mbps, т.е. время скачивания будет ещё меньше. Полноценный фильм в UHD объёмом около 30ГБ качается примерно за 15 минут на 300Mbps. Вас действительно не устраивает такое качество видео и время загрузки? Я совсем не придираюсь, просто лично для меня подождать 15 минут не является проблемой.
Я конечно далеко не эксперт в разных языках и парадигмах программирования, но тем не менее с этим утверждением я не согласен. Предусловия бывают самые разные, явные и неявные (подразумевающиеся). Как вы проверите, что вам передали указатель на последовательность символов, оканчивающуюся нулем? Если вызывающий код забудет дописать терминирующий ноль, вы этот факт никак не установите. Как вы проверите, что переданный в функцию указатель на структуру действительно указывает на такую структуру? Rust может гарантировать нечто подобное, но если данные пришли из внешнего источника их все равно придется валидировать. Любой самый защищенный язык при работе с низкоуровневыми абстракциями будет вынужден использовать unsafe секции кода. И там будут непроверяемые или сложнопроверяемые предусловия.
Разработчик обязан удовлетворить предусловия функции перед ее вызовом. В данном случае он обязан убедиться, что optional содержит значение, иначе получит неопределенное поведение. Как бы того ни хотел автор, но в любом языке программирования функции будут иметь предусловия, явные или неявные. Не все предусловия можно проверить. Не все проверки предусловий осуществимы за разумное время. Не все осуществимые проверки стоят того, чтобы быть выполненными. Сомневающихся прошу ознакомиться с данным документом. Всегда придется искать какой-то разумный компромисс. Язык C++ нацелен на максимальную производительность, поэтому написанные на нем библиотеки часто перекладывают на пользователя выполнение дополнительных проверок.
Хотя я не отрицаю, что современный C++ превратился в какого-то монстра и использовать его корректно очень и очень сложно, чтобы бросаться переносить существующие наработки, надо сначала создать хорошую замену C++. Языки с VM и сборщиком мусора не являются заменой по определению. Rust выглядит довольно перспективно, но тоже не без проблем.
А вообще, что они хотят? Они же замедлили твиттер, вот и реакцию теперь надо дольше ждать.
Подробнее можно почитать тут: A Resource Compiler with CMake and Standard C++