Вирус, рак, и другие подобные штуки - это проявления жизни и есть. Просто прикиньте, даже наши(и ладно бы грешные мы, но злокачественные образования бывают даже и у растений) собственные клетки норовят выйти из-под контроля и научиться жить самостоятельно (некоторым это даже почти удаётся!)
Нельзя сделать яичницу, не разбив яйца, невозможно жить, не уничтожая того, к чему прикасаешься. Даже если ты - не человек разумный, а просто белок. Причем, похоже, вся эта штука (с информационными технологиями, появляющимися за счёт копирующихся агентов) очень фундаментальная и даже не связана с законами физики Вселенной. Либо вечный покой, либо Величайшее Шоу на Земле.
Электромоторы - это как раз основа основ! Ладно даже жгутики, на электродинамических процессах вся биология и химия держится. Но это всё в наномасштабах.
Под колесом я подразумевал, разумеется, не что угодно катящееся, а именно функциональный узел многоклеточного организма. Там сложность в том, что без перехода проекта на новую архитектуру очень сложно организовать доставку питательных веществ в ротор. И я даже не говорю что это не реально, просто похоже, именно с этим у чисто биологической эволюциии пока не срослось.
В целях сравнения приходится иногда проводить границы :/ Я в целом к тому, что эволюция привела к появлению разума, который уже позволил систематизировать факты и преодолеть некоторые ограничения, которые без него преодолевать не получалось, по крайней мере у земной жизни.
Всё это несомненно "коллективное" достижение жизни как таковой, и, в принципе, от него вся жизнь может и выиграть, потому что если мы однажды таки поселимся на других планетах - наверняка завезём туда и своих соседей, потомков LUCA
Ещё бы, естественный отбор за миллиарды лет обкатал уже множество технологий.
Но даже он не всесилен, так как по своей природе ищет локальные экстремумы. Для реализации чего-то хорошего нужно не просто подсматривать, а разбираться как работает и сравнивать с теоретическими моделями, иногда подтягивая сами модели.
Справедливости ради, даже могучая земная жизнь без человеков умеет далеко не всё. Колёса, радиосвязь, космические аппараты, например.
UB - это не про поведение программы на целевой программы, а про разрешение компилятору генерировать какой угодно код при нарушении программистом контракта.
Случаи, когда компилятор сгенерировал именно тот код, который ожидал (горе-)программист, а в рантайме программа работает чёрт знает как, действительно редки, это те самые оставшиеся 5%
КМК смысл, помимо энтузиазма и интереса авторов, - в опробывании всяких новых подходов, парадигм и тд.
Да, многие старые языки нынче живее всех живых, и едва ли получится стать их "убийцами", но и живые они именно во многом потому что апгрейдятся фичами, зачастую отработанными именно в новых экспериментальных языках.
Не знаю, как именно работает gnu::noinline, но по идее нужно гарантировать, что компилятор не будет пытаться не только инлайнить, но и как бы то ни было оптимизировать этот вызов. Иначе же опять повыкидывает нафиг все вызовы перед окончанием лайфтаймов, и никакого "Secure" не будет.
Так код должен быть самодокументированным же, тогда таких проблем возникать не будет. Комментарий может пригодиться, например, для объяснения идеи какого-то хитрого алгоритма.
Если каждую строчку комментировать приходится - это ж придется потом читать и код и комментарии и еще их между собой сопоставлять придется.
Кажется, оверхед std::pair и tuple'ов в сравнении со struct может быть вызван наличием пользовательских конструкторов, которые хоть и делают семантически ровно то же, что мог бы сделать компилятор, но почему-то оптимизируются хуже
Вот да, за pmr особенно обидно, с самого C++17 уже есть удобный способ управлять размещением стандартных контейнеров в памяти, но вместо этого люди пытаются отказываться от них и писать велосипеды.
Да, даже допиленная в современных стандартах система аллокаторов, увы, не так удобна как бы хотелось, вложенные контейнеры может понадобиться учить принимать родительский аллокатор, но это очень мощное средство, позволяющее ускорить проблемное место зачастую буквально несколькими поправками к коду.
Насчет соседа все тоже не так просто: у человеков ведь культура сейчас эволюционирует быстрее чем "железо", и может статься что наставник может вложить в своих учеников больше индивидуальности, чем биологические родители.
С таким горизонтальным переносом мемов может получиться, что радоваться и помогать другим может быть даже более перспективной эволюционной стратегией, хоть это и нифига не интуитивно
Цели все-таки нет, но я вот тоже не думаю, что стоит бояться замены нас на кремниевую.
Даже если мы по всем параметрам будем уступать машинам и даже если мирное сосуществование не получится, они все равно наши прямые потомки. С точки зрения эволюции это несомненный успех!
Идеал недостижим, но, вообще говоря, для газоразрядных ламп плохая герметичность означает быстрый выход из строя, так что очень даже достойная.
И нет, благородные газы на то и благородные, что в химические реакции в нормальных условиях не вступают, так что сам по себе он канцерогенным быть не может, если только это не радиоактивный изотоп ( с радоном не путаете? Вот у этого парня стабильных изотопов не существует, и благодаря высокой плотности имеет свойство скапливаться в низинах и подземельях ). Гелий и неон используются в дыхательных смесях (как медицинских, так и для аквалангистов), аргон вовсю используют сварщики (для здоровья эта работа, конечно, не очень полезна, но инернтый газ - явно не превалирующий вредный фактор)
Чтобы работать и в одномерном и многомерном, с возможностью переходить от одного к другому, лучше использовать std::mdspan (или аналог, который будет работать в более старых стандартах).
Если извне приходит многомерный, то надежно сделать это без "обратного адаптирования"( с функцией вроде std::array<size_t, N> get_ndim_index(size_t) ) или побайтового копирования (std::memcpy) вряд ли удастся
Для этих целей отлично должна подойти библиотека SDL. Ее можно рассматривать как своеобразный фундамент для любых графических или игроподобных приложений.
В референсной реализации, как я понял, - хранит указатель на контрольный блок с виртуальными функциями clone, destroy и виртуальным деструктором. Присваивание с мувом приводит к перекидыванию указателя (при условии, что аллокаторы одинаковы)
Вирус, рак, и другие подобные штуки - это проявления жизни и есть. Просто прикиньте, даже наши(и ладно бы грешные мы, но злокачественные образования бывают даже и у растений) собственные клетки норовят выйти из-под контроля и научиться жить самостоятельно (некоторым это даже почти удаётся!)
Нельзя сделать яичницу, не разбив яйца, невозможно жить, не уничтожая того, к чему прикасаешься. Даже если ты - не человек разумный, а просто белок. Причем, похоже, вся эта штука (с информационными технологиями, появляющимися за счёт копирующихся агентов) очень фундаментальная и даже не связана с законами физики Вселенной. Либо вечный покой, либо Величайшее Шоу на Земле.
Электромоторы - это как раз основа основ! Ладно даже жгутики, на электродинамических процессах вся биология и химия держится. Но это всё в наномасштабах.
Под колесом я подразумевал, разумеется, не что угодно катящееся, а именно функциональный узел многоклеточного организма. Там сложность в том, что без перехода проекта на новую архитектуру очень сложно организовать доставку питательных веществ в ротор. И я даже не говорю что это не реально, просто похоже, именно с этим у чисто биологической эволюциии пока не срослось.
В целях сравнения приходится иногда проводить границы :/ Я в целом к тому, что эволюция привела к появлению разума, который уже позволил систематизировать факты и преодолеть некоторые ограничения, которые без него преодолевать не получалось, по крайней мере у земной жизни.
Всё это несомненно "коллективное" достижение жизни как таковой, и, в принципе, от него вся жизнь может и выиграть, потому что если мы однажды таки поселимся на других планетах - наверняка завезём туда и своих соседей, потомков LUCA
Ещё бы, естественный отбор за миллиарды лет обкатал уже множество технологий.
Но даже он не всесилен, так как по своей природе ищет локальные экстремумы. Для реализации чего-то хорошего нужно не просто подсматривать, а разбираться как работает и сравнивать с теоретическими моделями, иногда подтягивая сами модели.
Справедливости ради, даже могучая земная жизнь без человеков умеет далеко не всё. Колёса, радиосвязь, космические аппараты, например.
UB - это не про поведение программы на целевой программы, а про разрешение компилятору генерировать какой угодно код при нарушении программистом контракта.
Случаи, когда компилятор сгенерировал именно тот код, который ожидал (горе-)программист, а в рантайме программа работает чёрт знает как, действительно редки, это те самые оставшиеся 5%
КМК смысл, помимо энтузиазма и интереса авторов, - в опробывании всяких новых подходов, парадигм и тд.
Да, многие старые языки нынче живее всех живых, и едва ли получится стать их "убийцами", но и живые они именно во многом потому что апгрейдятся фичами, зачастую отработанными именно в новых экспериментальных языках.
Не знаю, как именно работает
gnu::noinline, но по идее нужно гарантировать, что компилятор не будет пытаться не только инлайнить, но и как бы то ни было оптимизировать этот вызов. Иначе же опять повыкидывает нафиг все вызовы перед окончанием лайфтаймов, и никакого "Secure" не будет.Спасибо за вводную статью!
Хочется добавить, что
std::mdspan- штука еще более универсальная, чем кажется на первый взгляд.Пользовательские стратегии
Extents, LayoutPolicy, AccessorPolicyпозволяют:отображать разные комбинации индексов на одни и те же элементы низлежащего массива (например, для симметричных матриц)
использовать вместо массива вообще произвольную структуру данных
не использовать вообще никакую память и вычислять значения на лету чистой функцией
вычислять значения на лету с побочными эффектами - например, обращаясь к операционной системе или датчику робота
владеть памятью/ресурсом, например, задействовав
std::vector/std::shared_ptr<const std::vector<T>>в качествеdata_handle_typeвычислять значения асинхронно
, Карл!И всё это - за единым статическим интерфейсом.
Примеры вдохновлены докладом Griswald Brooks на CppCon 2024
Так код должен быть самодокументированным же, тогда таких проблем возникать не будет. Комментарий может пригодиться, например, для объяснения идеи какого-то хитрого алгоритма.
Если каждую строчку комментировать приходится - это ж придется потом читать и код и комментарии и еще их между собой сопоставлять придется.
Конечно, не будет! unique_ptr - RAII обертка над самым обычным указателем, и никаких new в тайне от пользователя не делает.
Скорее всего, вы путаете сам unique_ptr с библиотечной функцией std::make_unique, которая является просто сокращенной записью вот этого:
unique_ptr<T>(new T(std::forward<Args>(args)...))Кажется, оверхед std::pair и tuple'ов в сравнении со struct может быть вызван наличием пользовательских конструкторов, которые хоть и делают семантически ровно то же, что мог бы сделать компилятор, но почему-то оптимизируются хуже
Вот да, за pmr особенно обидно, с самого C++17 уже есть удобный способ управлять размещением стандартных контейнеров в памяти, но вместо этого люди пытаются отказываться от них и писать велосипеды.
Да, даже допиленная в современных стандартах система аллокаторов, увы, не так удобна как бы хотелось, вложенные контейнеры может понадобиться учить принимать родительский аллокатор, но это очень мощное средство, позволяющее ускорить проблемное место зачастую буквально несколькими поправками к коду.
Насчет соседа все тоже не так просто: у человеков ведь культура сейчас эволюционирует быстрее чем "железо", и может статься что наставник может вложить в своих учеников больше индивидуальности, чем биологические родители.
С таким горизонтальным переносом мемов может получиться, что радоваться и помогать другим может быть даже более перспективной эволюционной стратегией, хоть это и нифига не интуитивно
Цели все-таки нет, но я вот тоже не думаю, что стоит бояться замены нас на кремниевую.
Даже если мы по всем параметрам будем уступать машинам и даже если мирное сосуществование не получится, они все равно наши прямые потомки. С точки зрения эволюции это несомненный успех!
Идеал недостижим, но, вообще говоря, для газоразрядных ламп плохая герметичность означает быстрый выход из строя, так что очень даже достойная.
И нет, благородные газы на то и благородные, что в химические реакции в нормальных условиях не вступают, так что сам по себе он канцерогенным быть не может, если только это не радиоактивный изотоп ( с радоном не путаете? Вот у этого парня стабильных изотопов не существует, и благодаря высокой плотности имеет свойство скапливаться в низинах и подземельях ). Гелий и неон используются в дыхательных смесях (как медицинских, так и для аквалангистов), аргон вовсю используют сварщики (для здоровья эта работа, конечно, не очень полезна, но инернтый газ - явно не превалирующий вредный фактор)
Чтобы работать и в одномерном и многомерном, с возможностью переходить от одного к другому, лучше использовать
std::mdspan(или аналог, который будет работать в более старых стандартах).Если извне приходит многомерный, то надежно сделать это без "обратного адаптирования"( с функцией вроде
std::array<size_t, N> get_ndim_index(size_t)) или побайтового копирования (std::memcpy) вряд ли удастсяКажется, это проявление феномена Баадера - Майнхоф ;)
Для этих целей отлично должна подойти библиотека SDL. Ее можно рассматривать как своеобразный фундамент для любых графических или игроподобных приложений.
Рисовать массив цветных точек можно как-то вот так (первый нагугленный пример) : https://gist.github.com/mmozeiko/729860eeb414f1a2ee345d9d3ab4dd4e
В референсной реализации, как я понял, - хранит указатель на контрольный блок с виртуальными функциями clone, destroy и виртуальным деструктором. Присваивание с мувом приводит к перекидыванию указателя (при условии, что аллокаторы одинаковы)
Там еще довольно много отличий, вытекающих как раз из специфики типов-значений, вот что сходу вспомнилось:
распространение константности на хранимый объект
поддержка аллокаторов
автоматическое оборачивание операторов сравнения (бинарных и
operator<=>) иstd::hashну и да, автоматическое копирование и перемещение значения (в случае с
std::polymorphicэто еще и изящно решает проблему клонирования)Есть референсная реализация, которую можно использовать уже сейчас