Кажется, оверхед std::pair и tuple'ов в сравнении со struct может быть вызван наличием пользовательских конструкторов, которые хоть и делают семантически ровно то же, что мог бы сделать компилятор, но почему-то оптимизируются хуже
Вот да, за pmr особенно обидно, с самого C++17 уже есть удобный способ управлять размещением стандартных контейнеров в памяти, но вместо этого люди пытаются отказываться от них и писать велосипеды.
Да, даже допиленная в современных стандартах система аллокаторов, увы, не так удобна как бы хотелось, вложенные контейнеры может понадобиться учить принимать родительский аллокатор, но это очень мощное средство, позволяющее ускорить проблемное место зачастую буквально несколькими поправками к коду.
Насчет соседа все тоже не так просто: у человеков ведь культура сейчас эволюционирует быстрее чем "железо", и может статься что наставник может вложить в своих учеников больше индивидуальности, чем биологические родители.
С таким горизонтальным переносом мемов может получиться, что радоваться и помогать другим может быть даже более перспективной эволюционной стратегией, хоть это и нифига не интуитивно
Цели все-таки нет, но я вот тоже не думаю, что стоит бояться замены нас на кремниевую.
Даже если мы по всем параметрам будем уступать машинам и даже если мирное сосуществование не получится, они все равно наши прямые потомки. С точки зрения эволюции это несомненный успех!
Идеал недостижим, но, вообще говоря, для газоразрядных ламп плохая герметичность означает быстрый выход из строя, так что очень даже достойная.
И нет, благородные газы на то и благородные, что в химические реакции в нормальных условиях не вступают, так что сам по себе он канцерогенным быть не может, если только это не радиоактивный изотоп ( с радоном не путаете? Вот у этого парня стабильных изотопов не существует, и благодаря высокой плотности имеет свойство скапливаться в низинах и подземельях ). Гелий и неон используются в дыхательных смесях (как медицинских, так и для аквалангистов), аргон вовсю используют сварщики (для здоровья эта работа, конечно, не очень полезна, но инернтый газ - явно не превалирующий вредный фактор)
Чтобы работать и в одномерном и многомерном, с возможностью переходить от одного к другому, лучше использовать std::mdspan (или аналог, который будет работать в более старых стандартах).
Если извне приходит многомерный, то надежно сделать это без "обратного адаптирования"( с функцией вроде std::array<size_t, N> get_ndim_index(size_t) ) или побайтового копирования (std::memcpy) вряд ли удастся
Для этих целей отлично должна подойти библиотека SDL. Ее можно рассматривать как своеобразный фундамент для любых графических или игроподобных приложений.
В референсной реализации, как я понял, - хранит указатель на контрольный блок с виртуальными функциями clone, destroy и виртуальным деструктором. Присваивание с мувом приводит к перекидыванию указателя (при условии, что аллокаторы одинаковы)
Кстати, вопреки распространенному мнению, конкретно ложные лисички (ака оранжевые говорушки) не ядовиты, некоторые их даже намеренно собирают. Та же фигня с большинством ложных опят, да и легендарный "ложный подберезовик" на поверку оказывается невкусным, но совершенно безопасным грибом.
Что, разумеется, не отменяет существование действительно очень опасных грибов, которые иногда даже опытные грибники умудряются путать со съедобными.
Похоже, что именно соображения безопасности привели к выбору для заготовок довольно характерных грибов - белые, маслята, млечники (вроде груздей и рыжиков), лисички. Эти ребята - бро, спутать их с чем-то опасным практически невозможно (тем не менее, принцип "не знаешь - не бери" надо соблюдать всегда)
Cтандартный аллокатор неизбежно сделает что-то вроде:
установит мьютекc или применит любой другой доступный способ синхронизации
обратится к ОС за памятью
ОС выполнит довольно заковыристый алгоритм для поддержания структуры данных heap'а.
Полагаю, на практике разработчики стандартной библиотеки могут в целях оптимизации не всегда бегать за памятью к системе, а поддерживать собственные кеши - тогда часть работы перемещается на библиотеку, системный вызов осуществляется время от времени. Но поддержка потокобезопасности и общее назначение алгоритма аллокации все равно выходят дорого, по сравнению с потенциальной пользой от специализированной стратегии аллокации.
По сравнению с этим, вызов виртуальной функции (всего-то два перехода по указателю) - просто капля в море. Современные компиляторы этот вызов еще и зачастую девиртуализировать могут.
в общем случае интерфейс сstd::vector, конечно, малость оверхед(будет хорошо работать только при условии, что временные объекты не создаются), правильная альтернатива - std::span (если нам позарез нужен указатель на массив в памяти, например, для передачи в C API), ну и пара итераторов/диапазон для работы с "конвенционными" контейнерами C++
Концептуально, причина возникновения рака всегда одна - неудачные сбои копирования генома клеток. Ошибки в копировании случаются и без внешних причин, и в общем-то это - норма и движущая сила эволюции. Проблема в том, что злокачественная опухоль - это и есть результат эволюции, эволюции линии клеток, вырвавшихся из-под контроля организма. Известны даже случаи, когда подобные линии клеток переживали хозяев, фактически становясь самостоятельными биологическими видами, ака "трансмиссивная злокачественная опухоль"
Во всех нас, даже трижды здоровых людях, живущих в идеальных экологических условиях, постоянно возникают клетки с потенциально опасными мутациями. Для того, чтобы заболеть, всегда нужно очень неудачное стечение обстоятельств: каскад приспособлений для независимости, и игнор со стороны имунной системы.
Хотя вредные факторы вроде химических мутагенов или ионизирующего излучения могут многократно увеличить риск, это всегда результат случайного процесса.
Пошел он в народ, пошел. Если говорить о личном опыте - то у нас в 2010ых все знакомые именно 3.58 гоняли и друг другу копировали, мне тоже именно ее посоветовали.
Но WOG уж очень забагованный был, вылет на ровном месте во время твоего, или, что еще хуже, хода ИИ - обычное дело. Когда появилась Хота, органично и сбалансированно расширяющая игру и развивающаяся совместно с HD модом - она быстро стала доминировать
В Skype точно было. Причем оно умудрялось распознавать два разных случая - когда тыкают рандомные клавиши, собеседник видел ломающийся карандаш, а при зажатии нескольких - собственно котэ
Конечно, не будет! 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это еще и изящно решает проблему клонирования)Есть референсная реализация, которую можно использовать уже сейчас
Кстати, вопреки распространенному мнению, конкретно ложные лисички (ака оранжевые говорушки) не ядовиты, некоторые их даже намеренно собирают. Та же фигня с большинством ложных опят, да и легендарный "ложный подберезовик" на поверку оказывается невкусным, но совершенно безопасным грибом.
Что, разумеется, не отменяет существование действительно очень опасных грибов, которые иногда даже опытные грибники умудряются путать со съедобными.
Похоже, что именно соображения безопасности привели к выбору для заготовок довольно характерных грибов - белые, маслята, млечники (вроде груздей и рыжиков), лисички. Эти ребята - бро, спутать их с чем-то опасным практически невозможно (тем не менее, принцип "не знаешь - не бери" надо соблюдать всегда)
Cтандартный аллокатор неизбежно сделает что-то вроде:
установит мьютекc или применит любой другой доступный способ синхронизации
обратится к ОС за памятью
ОС выполнит довольно заковыристый алгоритм для поддержания структуры данных heap'а.
Полагаю, на практике разработчики стандартной библиотеки могут в целях оптимизации не всегда бегать за памятью к системе, а поддерживать собственные кеши - тогда часть работы перемещается на библиотеку, системный вызов осуществляется время от времени. Но поддержка потокобезопасности и общее назначение алгоритма аллокации все равно выходят дорого, по сравнению с потенциальной пользой от специализированной стратегии аллокации.
По сравнению с этим, вызов виртуальной функции (всего-то два перехода по указателю) - просто капля в море. Современные компиляторы этот вызов еще и зачастую девиртуализировать могут.
в общем случае интерфейс с
std::vector, конечно, малость оверхед(будет хорошо работать только при условии, что временные объекты не создаются), правильная альтернатива -std::span(если нам позарез нужен указатель на массив в памяти, например, для передачи в C API), ну и пара итераторов/диапазон для работы с "конвенционными" контейнерами C++Концептуально, причина возникновения рака всегда одна - неудачные сбои копирования генома клеток.
Ошибки в копировании случаются и без внешних причин, и в общем-то это - норма и движущая сила эволюции. Проблема в том, что злокачественная опухоль - это и есть результат эволюции, эволюции линии клеток, вырвавшихся из-под контроля организма. Известны даже случаи, когда подобные линии клеток переживали хозяев, фактически становясь самостоятельными биологическими видами, ака "трансмиссивная злокачественная опухоль"
Во всех нас, даже трижды здоровых людях, живущих в идеальных экологических условиях, постоянно возникают клетки с потенциально опасными мутациями. Для того, чтобы заболеть, всегда нужно очень неудачное стечение обстоятельств: каскад приспособлений для независимости, и игнор со стороны имунной системы.
Хотя вредные факторы вроде химических мутагенов или ионизирующего излучения могут многократно увеличить риск, это всегда результат случайного процесса.
Спасибо за комментарий, намеренно искал, написал ли кто-то уже об этом.
И кмк это ведь как раз одно из важнейших нововведений C++14, оказавшее огромное влияние на написание кода.
Здорово, конечно, но давно же существует gsudo, которая делает все то, что обещают Майкрософтовцы.
Авторам оригинальной тулзы, наверное, щас обидно было...
Пошел он в народ, пошел. Если говорить о личном опыте - то у нас в 2010ых все знакомые именно 3.58 гоняли и друг другу копировали, мне тоже именно ее посоветовали.
Но WOG уж очень забагованный был, вылет на ровном месте во время твоего, или, что еще хуже, хода ИИ - обычное дело. Когда появилась Хота, органично и сбалансированно расширяющая игру и развивающаяся совместно с HD модом - она быстро стала доминировать
а лично мне Виста понравилась сразу с момента выхода, даже больше чем 7
В Skype точно было. Причем оно умудрялось распознавать два разных случая - когда тыкают рандомные клавиши, собеседник видел ломающийся карандаш, а при зажатии нескольких - собственно котэ