В идеальном мире система сборки должна быть на 100% декларативной.
Увы, в реальности это практически невозможно. Всегда будет целая куча моментов, которые заранее в системе сборки предусмотреть невозможно, и которые будут скриптовать, кастомизировать, автоматизировать и т. д. и т. п. Остается только выбор будет ли это скрипт в рамках самой системы сборки (хоть сколько-нибудь единообразный и интегрируемый в остальную систему), или внешний костыль на bash/Python/etc.
CMake давным давно начал как по большей части императивный скрипт, с тех пор старается все сделать максимально декларативно, но полностью от императивности никогда не избавится.
Абстракция опции для сборки протекла под Windows с релизом толи MSVC 2012, то ли MSVC 2015, и архитектура указывается теперь специальным образом.
Не думаю, что это CMake виноват, что задание архитерктуры формализовано/стандартизовано только для системы сборки MSBuild.
Если бы у других систем сборки (Makefiles, Ninja и т. п.) были бы какие-то стандартные механизмы для выбора архитектуры, тогда наверное CMake смог бы абстрагировать эту опцию единым для всех образом.
Как выше уже отметили, JSON и не-JSON для одного инструмента, для ручного редактирования - ну такое.
Выглядит конечно так себе, но есть ли какие-то другие варианты?
Конфигурационный файл пресетов на языке CMake? CMakeLists.txt на JSON? Один другого хуже.
Кроме того, CMakeLists.txt это вынужденно императивный язык. А конфиги пресетов -- это именно конфиги, просто декларативный набор данных. В какой-то мере это как жаловаться что у C++ и clang-format разный синтаксис =).
Вообще если уж придираться к формату -- я бы пожаловался на выбор JSON для конфигов, которые явно будут часто редактироваться вручную. Ну есть же YAML (напоминаю, что JSON это подмножество YAML, по сути YAML это JSON с возможностью нормального, человеческого форматирования).
А если еще и CMakeCache.txt в расчет брать
А не надо CMakeCache.txt брать =) это внутренние дела CMake. Могут вообще в любой момент его формат поменять и будут правы.
Raspberry Pi там ни зачем особенно, в рамках своей концепции такой ноубук мог бы использовать любой другой одноплатник.
Просто Raspberry Pi самый надежный выбор: хорошо известный, документированный, повсеместно доступный одноплатный компьютер с вариантом исполнения в виде compute module, и ко всему прочему с гарантированным сроком производства и поддержки.
И одноплатный компьютер там очевидно не для того, чтобы на питоне через GPIO светодиодами мигать (хотя предусмотреть какой-нибудь разъем для них было бы логично, а вдруг все-таки), а просто как вариант такой вот унифицированной материнской платы.
Понятное дело что устройство будет очень нишевое. Но как очень крутая док-станция к используемому в роли мини-ПК одноплатнику -- вполне может найти применение. Я бы например взял для тестирования кросс-разработки/портирования под ARM -- покупать ультрабук на Snapdragon жабненько, а постоянно держать Raspberry Pi на столе с кучей проводов неудобно.
матрицу, которая по карману среднему DIY-щику <...> Но матрицы 36х24, пригодные для такого дела, я пока не встречал
А какие матрицы 36x24, пригодные для других дел вы встречали? =)
Доступных DIY матриц нормального размера вообще нет. Только мобильные сенсоры максимум 1/1.33" размером. Даже 1" не найти, что уж там говорить о полном кадре.
Чисто физически большую матрицу несложно купить в виде запчасти от какого-нибудь фотоаппарата, но ключевая проблема в том, что на них нет документации. Без подробных даташитов матрица это просто забавный сувенир.
В принципе, сенсоры с даташитами вам продадут, но только крупной партией и на индивидуально оговариваемых условиях. То есть не DIY.
Я бы с удовольствием попробовал бы сделать самодельную камеру, но увы, обычному инженеру-одиночке недоступны ни сенсор нормального размера, ни автофокусные объективы.
Panasonic: последняя зеркальная модель была выпущена в 2007 году.
Fujifilm: в 2007 году.
Olympus: в 2011 году.
Sony: в 2016 году (A99II). С тех пор Sony выпустили 15 беззеркальных моделей. В данный момент в официальном каталоге зеркальных моделей нет.
Canon: в январе 2020 года (1DX mkIII). С тех пор выпущено 14 беззеркальных моделей. В текущем каталоге есть по сути две серьезные зеркальные камеры (1DX mkIII и 5D mkIV) плюс 3-4 модели Rebel в зависимости от региона. Любопытно, что Canon были единственными кто уже в момент выпуска 1DX mkIII прямо признался что все, это последняя зеркальная модель.
Nikon: в феврале 2020 года (D6). С тех пор было выпущено 10 беззеркальных моделей. В текущем каталоге зеркальные камеры представлены четырьмя моделями 2017-2020 года выпуска.
Вышеперечисленные пять производителей занимают 95% рынка фотокамер. С практической точки зрения можно считать что зеркальные камеры уже не выпускаются.
Canon и Nikon предсказуемо были последними, кто полностью перешел на беззеркальную конструкцию -- с учетом размеров их пользовательской базы в то время, не так-то просто было взять и сменить технологию.
В итоге Nikon поплатились за эту неповоротливость: с уверенного второго места и серьезного конкурента Canon они скатились далеко на третье (всего 11% рынка).
Canon, Sony, Nikon, Fujifilm, Leica, Panasonic, OM (бывший Olympus) -- не выпускают зеркальные камеры уже много лет, а разработка новых была прекращена ещё раньше.
Это 99% рынка.
Даже если какой-нибудь Pentax производит несколько штук в год или если в некоторых магазинах до сих пор можно найти зеркалку Canon 2015 года выпуска в заводской упаковке -- ситуацию не меняет. Плёночные камеры тоже формально выпускают и их все ещё можно купить. Тем не менее плёночные камеры уже давно все и зеркалки тоже.
Плёночные камеры тоже. Суть в том, что зеркалки уже долгое время не выпускаются ни одним из сколь-нибудь заметных производителей на рынке. Зеркалка более не является синонимом слова фотоаппарат.
И судя по всему, все так же либо WSL2, либо VirtualBox -- включение WSL2 автоматически включает Hyper-V, а VirtualBox вместе с ним нормально работать не может, сваливаясь в какой-то очень медленный режим виртуализации.
возможно это вас удивит но в unicode влез не весь китайский и так было с самого начала его появления
Unicode намного, намного шире всего CJK вообще и китайского в частности.
Азиаты до сих пор используют не юникод кодировки ровно по той же причине, по которой не азиаты до сих пор используют не юникод -- грубо говоря, "исторически сложилось".
Вы же не будете утверждать, что кириллица не влезла в Unicode только лишь потому, что до сих пор в быту встречается Windows-1251?
Пока коробку не откроют, кошка одновременно жива и мертва — это суперпозиция двух состояний
Шрёдингер, используя в дискуссии с Энштейном прием доведения до абсурда: да я вообще могу придумать простую модель, в которой состояние например кота оказывается в суперпозиции, а поскольку этого очевидно быть не может, получается что обсуждаемое волновое представление материи не является полным.
Весь мир много лет спустя: ух ты Шрёдингер говорит кот одновременно и жив и мертв.
И да, и не совсем. Я может быть не могу лично посмотреть со стороны на планету, но вполне могу сравнить какая теория о ее форме лучше согласуется с действительностью, начиная от простой логики и заканчивая всякими локальными экспериментами.
Так же и про технологию сенсорного экрана. Может быть именно такой же стеклянный бутерброд вы изготовить не сможете, но получить степень диванного магистра в области электротехники, разнести мастерскую в процессе пайки ёмкостного датчика и сделать вывод, что с достаточной долей вероятности там то же самое, только помельче -- запросто.
А иначе получается, что и в лично собранном генераторе могут по обмоткам микро-зевсы бегать =).
критически важное программное обеспечение должно отказаться от C/C++ к 2026 году
Ммм, не совсем.
У компаний есть время до 1 января 2026 года, чтобы составить планы по обеспечению безопасности памяти <...> отсутствие опубликованной дорожной карты по обеспечению безопасности памяти к 1 января 2026 года опасно и значительно повышает риск для национальной безопасности
К 2026 году компании должны придумать как они будут отказываться от C/C++ в течении неопределенного времени.
А там или шах помрёт, или cpp2 зарелизят, или Safe C++ в стандарт завезут.
Это так не работает. Вывод типа выполняется до генерации какого-либо кода
Это как это вывод типа auto без trailing return type работает до генерации кода return?
Да, в рантайме. И она их не производит
Поэтому программный код, который расходится с этим утверждением, компилируется не всегда предсказуемым образом. Я бы даже сказал часто очень неожиданным образом компилируется =).
Слово "поведение" в словосочетании "неопределенное поведение" относится к поведению виртуальной машины C++ <...> Не нужно распространять понятие UB на компилятор
Да, фундаментально UB это наблюдаемое неопределенное поведение как результат буквального выполнения ошибочных инструкций.
Но компилятор не просто транслирует код один к одному, он еще пытается выполнять всяческие оптимизации, в том числе исходя из предположения что никакого UB в природе нет и быть не может.
В ряде случаев попытка скомпилировать код, в котором есть UB, будучи уверенным что ничего там нет, вместо корректной оптимизации приводит к некорректной и непредсказуемой модификации исходной программы.
Поэтому изначальное утверждение, которому я оппонировал:
Добавлять что-то к nullptr - это UB, только если до этой операции дойдёт выполнение
Не выглядит справедливым. Наличие UB в коде может привести и нередко приводит к непредсказуемым последствиям в плане генерируемого кода, делая поведение не определенным стандартом даже если фактически выполнение до этой конкретной операции еще не дошло.
никакого UB быть не может, поскольку никакого кода, который мог бы выполняться при вызове do_something(), вообще не генерируется
template<typename T> auto do_something(T&&) {
/* какое-нибудь UB */
}
Гипотетически компилятор натыкается на нестыковку, оптимизирует do_something() до return nullptr; и вуаля, decltype() возвращает вообще не то. Хотя никакого кода не генерируется и более того, в стандарте прямым текстом написано, что передаваемое выражение НЕ выполняется.
Пример конечно очень частный, но иллюстрирует что лучше никогда не говорить "никогда" =) особенно если поведение программы буквально не определено.
Пока код с UB не исполняется в реальности, UB не существует.
Но возможное наличие UB сказывается на генерируемой программе еще во время ее компиляции.
UB - это runtime concept, а не compile-time.
Потому что нет, это не только runtime concept.
Помимо названия для последствий некоторых действий, это еще и негласное обещание компилятору, что программа таких действий производить не будет.
На основе этого обещания компилятор делает самые разные выводы как раз-таки в compile time, в основном в целях оптимизации. Думаю многие видели как потенциальное UB приводит к изменению фактического алгоритма вплоть до неузнаваемости еще задолго до его выполнения.
13 февраля проект покинул один из его основателей и ключевых разработчиков, Hector Mertin:
https://www.phoronix.com/news/Hector-Martin-Resigns-Asahi
А 18 марта ушел ещё один ключевой разработчик, Asahi Lina, которая едва ли не в одиночку тащила разработку/реверс-инжиниринг драйверов GPU:
https://www.phoronix.com/news/Asahi-Lina-Steps-Down-Linux-GPU
(Есть теория, что это на самом деле один человек.)
В общем, есть некоторые опасения касаемо будущего проекта =(.
И потом портят его спорным DE.
Цены бы макбукам на M1 не было, если бы не macOS.
(личное мнение автора комментария)
В идеальном мире система сборки должна быть на 100% декларативной.
Увы, в реальности это практически невозможно. Всегда будет целая куча моментов, которые заранее в системе сборки предусмотреть невозможно, и которые будут скриптовать, кастомизировать, автоматизировать и т. д. и т. п. Остается только выбор будет ли это скрипт в рамках самой системы сборки (хоть сколько-нибудь единообразный и интегрируемый в остальную систему), или внешний костыль на bash/Python/etc.
CMake давным давно начал как по большей части императивный скрипт, с тех пор старается все сделать максимально декларативно, но полностью от императивности никогда не избавится.
Не думаю, что это CMake виноват, что задание архитерктуры формализовано/стандартизовано только для системы сборки MSBuild.
Если бы у других систем сборки (Makefiles, Ninja и т. п.) были бы какие-то стандартные механизмы для выбора архитектуры, тогда наверное CMake смог бы абстрагировать эту опцию единым для всех образом.
Выглядит конечно так себе, но есть ли какие-то другие варианты?
Конфигурационный файл пресетов на языке CMake? CMakeLists.txt на JSON? Один другого хуже.
Кроме того, CMakeLists.txt это вынужденно императивный язык. А конфиги пресетов -- это именно конфиги, просто декларативный набор данных. В какой-то мере это как жаловаться что у C++ и clang-format разный синтаксис =).
Вообще если уж придираться к формату -- я бы пожаловался на выбор JSON для конфигов, которые явно будут часто редактироваться вручную. Ну есть же YAML (напоминаю, что JSON это подмножество YAML, по сути YAML это JSON с возможностью нормального, человеческого форматирования).
А не надо CMakeCache.txt брать =) это внутренние дела CMake. Могут вообще в любой момент его формат поменять и будут правы.
Raspberry Pi там ни зачем особенно, в рамках своей концепции такой ноубук мог бы использовать любой другой одноплатник.
Просто Raspberry Pi самый надежный выбор: хорошо известный, документированный, повсеместно доступный одноплатный компьютер с вариантом исполнения в виде compute module, и ко всему прочему с гарантированным сроком производства и поддержки.
И одноплатный компьютер там очевидно не для того, чтобы на питоне через GPIO светодиодами мигать (хотя предусмотреть какой-нибудь разъем для них было бы логично, а вдруг все-таки), а просто как вариант такой вот унифицированной материнской платы.
Понятное дело что устройство будет очень нишевое. Но как очень крутая док-станция к используемому в роли мини-ПК одноплатнику -- вполне может найти применение. Я бы например взял для тестирования кросс-разработки/портирования под ARM -- покупать ультрабук на Snapdragon жабненько, а постоянно держать Raspberry Pi на столе с кучей проводов неудобно.
А какие матрицы 36x24, пригодные для других дел вы встречали? =)
Доступных DIY матриц нормального размера вообще нет. Только мобильные сенсоры максимум 1/1.33" размером. Даже 1" не найти, что уж там говорить о полном кадре.
Чисто физически большую матрицу несложно купить в виде запчасти от какого-нибудь фотоаппарата, но ключевая проблема в том, что на них нет документации. Без подробных даташитов матрица это просто забавный сувенир.
В принципе, сенсоры с даташитами вам продадут, но только крупной партией и на индивидуально оговариваемых условиях. То есть не DIY.
Я бы с удовольствием попробовал бы сделать самодельную камеру, но увы, обычному инженеру-одиночке недоступны ни сенсор нормального размера, ни автофокусные объективы.
Да какие тут иллюзии? В хронологическом порядке:
Panasonic: последняя зеркальная модель была выпущена в 2007 году.
Fujifilm: в 2007 году.
Olympus: в 2011 году.
Sony: в 2016 году (A99II). С тех пор Sony выпустили 15 беззеркальных моделей. В данный момент в официальном каталоге зеркальных моделей нет.
Canon: в январе 2020 года (1DX mkIII). С тех пор выпущено 14 беззеркальных моделей. В текущем каталоге есть по сути две серьезные зеркальные камеры (1DX mkIII и 5D mkIV) плюс 3-4 модели Rebel в зависимости от региона. Любопытно, что Canon были единственными кто уже в момент выпуска 1DX mkIII прямо признался что все, это последняя зеркальная модель.
Nikon: в феврале 2020 года (D6). С тех пор было выпущено 10 беззеркальных моделей. В текущем каталоге зеркальные камеры представлены четырьмя моделями 2017-2020 года выпуска.
Вышеперечисленные пять производителей занимают 95% рынка фотокамер. С практической точки зрения можно считать что зеркальные камеры уже не выпускаются.
Canon и Nikon предсказуемо были последними, кто полностью перешел на беззеркальную конструкцию -- с учетом размеров их пользовательской базы в то время, не так-то просто было взять и сменить технологию.
В итоге Nikon поплатились за эту неповоротливость: с уверенного второго места и серьезного конкурента Canon они скатились далеко на третье (всего 11% рынка).
Canon, Sony, Nikon, Fujifilm, Leica, Panasonic, OM (бывший Olympus) -- не выпускают зеркальные камеры уже много лет, а разработка новых была прекращена ещё раньше.
Это 99% рынка.
Даже если какой-нибудь Pentax производит несколько штук в год или если в некоторых магазинах до сих пор можно найти зеркалку Canon 2015 года выпуска в заводской упаковке -- ситуацию не меняет. Плёночные камеры тоже формально выпускают и их все ещё можно купить. Тем не менее плёночные камеры уже давно все и зеркалки тоже.
Плёночные камеры тоже. Суть в том, что зеркалки уже долгое время не выпускаются ни одним из сколь-нибудь заметных производителей на рынке. Зеркалка более не является синонимом слова фотоаппарат.
Оффтоп:
Интересно сколько ещё люди будут по старой привычке называть системные камеры зеркалками? =)
Отдельно иронично, что в "настоящих" камерах зеркал уже давно нет, а вот в смартфонах они часто есть, хоть и выполняют конечно совсем другую функцию.
Автор же прямо написал:
Он отрезал экран не для того, чтобы носить очки, а потому что он все равно носит очки и экран оказывается лишним.
И судя по всему, все так же либо WSL2, либо VirtualBox -- включение WSL2 автоматически включает Hyper-V, а VirtualBox вместе с ним нормально работать не может, сваливаясь в какой-то очень медленный режим виртуализации.
https://github.com/MicrosoftDocs/WSL/issues/798
Unicode намного, намного шире всего CJK вообще и китайского в частности.
Азиаты до сих пор используют не юникод кодировки ровно по той же причине, по которой не азиаты до сих пор используют не юникод -- грубо говоря, "исторически сложилось".
Вы же не будете утверждать, что кириллица не влезла в Unicode только лишь потому, что до сих пор в быту встречается Windows-1251?
Весь интересный простому обывателю софт уже давно есть в варианте под ARM:
https://armrepo.ver.lt/
Шрёдингер, используя в дискуссии с Энштейном прием доведения до абсурда: да я вообще могу придумать простую модель, в которой состояние например кота оказывается в суперпозиции, а поскольку этого очевидно быть не может, получается что обсуждаемое волновое представление материи не является полным.
Весь мир много лет спустя: ух ты Шрёдингер говорит кот одновременно и жив и мертв.
И да, и не совсем. Я может быть не могу лично посмотреть со стороны на планету, но вполне могу сравнить какая теория о ее форме лучше согласуется с действительностью, начиная от простой логики и заканчивая всякими локальными экспериментами.
Так же и про технологию сенсорного экрана. Может быть именно такой же стеклянный бутерброд вы изготовить не сможете, но получить степень диванного магистра в области электротехники, разнести мастерскую в процессе пайки ёмкостного датчика и сделать вывод, что с достаточной долей вероятности там то же самое, только помельче -- запросто.
А иначе получается, что и в лично собранном генераторе могут по обмоткам микро-зевсы бегать =).
Sony упорно вставляет.
Ммм, не совсем.
К 2026 году компании должны придумать как они будут отказываться от C/C++ в течении неопределенного времени.
А там или шах помрёт, или cpp2 зарелизят, или Safe C++ в стандарт завезут.
Это как это вывод типа auto без trailing return type работает до генерации кода return?
Поэтому программный код, который расходится с этим утверждением, компилируется не всегда предсказуемым образом. Я бы даже сказал часто очень неожиданным образом компилируется =).
Да, фундаментально UB это наблюдаемое неопределенное поведение как результат буквального выполнения ошибочных инструкций.
Но компилятор не просто транслирует код один к одному, он еще пытается выполнять всяческие оптимизации, в том числе исходя из предположения что никакого UB в природе нет и быть не может.
В ряде случаев попытка скомпилировать код, в котором есть UB, будучи уверенным что ничего там нет, вместо корректной оптимизации приводит к некорректной и непредсказуемой модификации исходной программы.
Поэтому изначальное утверждение, которому я оппонировал:
Не выглядит справедливым. Наличие UB в коде может привести и нередко приводит к непредсказуемым последствиям в плане генерируемого кода, делая поведение не определенным стандартом даже если фактически выполнение до этой конкретной операции еще не дошло.
Гипотетически компилятор натыкается на нестыковку, оптимизирует
do_something()доreturn nullptr;и вуаля,decltype()возвращает вообще не то. Хотя никакого кода не генерируется и более того, в стандарте прямым текстом написано, что передаваемое выражение НЕ выполняется.Пример конечно очень частный, но иллюстрирует что лучше никогда не говорить "никогда" =) особенно если поведение программы буквально не определено.
Но возможное наличие UB сказывается на генерируемой программе еще во время ее компиляции.
Потому что нет, это не только runtime concept.
Помимо названия для последствий некоторых действий, это еще и негласное обещание компилятору, что программа таких действий производить не будет.
На основе этого обещания компилятор делает самые разные выводы как раз-таки в compile time, в основном в целях оптимизации. Думаю многие видели как потенциальное UB приводит к изменению фактического алгоритма вплоть до неузнаваемости еще задолго до его выполнения.