И контейнеры позволяют ручную реаллокацию. В отличие от ручного realloc() -- безопасно и аккуартно.
Есть контейнеры, которые уже реализуют варианты кусочно-линейных представлений, есть контейнеры, предоставляющие цельные куски по требованию, есть списки и деревья разных цветов и пород.
Вы правда утверждаете, что ручное выделение, которое написали вы сами, будет работать лучше ручного выделения, которое написал кто-то другой?
Или ваша ручная реализация спокойно поменяет 200 тысяч на 300 миллионов вершин магическим образом, не уходя в никакой лаг?.. Сами же говорите, что нет. Так к чему этот пример был?
Да блин, посмотрите любые потроха контейнерных классов. Или там просто так, пару сотен тысяч строк кода ?
Я их видел много кратно. Нет, не просто так. Однако активное использование шаблонов и constexpr -- позволяют оплатить их во время компиляции. unique_ptr делает кучу проверок... Которых не остаётся в скомпилированом коде. Вот простейший синтетический пример: https://godbolt.org/z/ePE68Pob3
Вы вообще знаете, что к примеру, для игр, используют не просто "сырые" указатели, а вообще, самопальные версии "new/malloc" (ну, понятное дело, с нужной обвязкой)?
"Свой аллокатор" это очень полезная штука, не только в геймдеве. Причем код, работающий на контейнерах, прекрасно можно переиспользовать в одном приложении сразу используя с разными аллокаторами без ручного управления.
Поучительно.
Да, вам стоит почитать исходники и посмотреть на результат компиляции. Это действительно поучительно.
Действительно есть места, где стандартные контейнеры не подходят, но ответ почему не подходят должен быть осмысленен, оценен и подтвержден -- а не просто проекция страхов на уровне "кто-то там когда-то во времена атлона напел".
А можно не "на глаз" а с примером? Повторюсь: оплата идёт в момент компиляции при аккуратном применении. Тот же unique_ptr буквально компилируется в один указатель, никакой разницы с сырым указателем нет от слова совсем. std::array<X> ничем не отличается от X[], кроме дополнительной безопасности и контроля во время компиляции. Какие именно контейнеры уступают чему именно, можно примеры? А то попахивает что перемножаем яблоки на апельсины и жалуемся что на выходе лампальсины.
А если говорить про "чудесный геймдев"... Я вот вижу насколько блюпринты медленнее си -- и ведь не сказать что все бросили все блюпы нафиг и обходят их за километр, да?
Когда-то давным давно, когда земля была раскаленным шаром, а C -- макроассемблером на стероидах, switch это был способ задать таблицу переходов в исходнике (а не просто синтаксическим сахаром). Но да, даже тогда, это не было "за одно сравнение", те же проверки на на отрицательные, на больше максимума и так далее необходимы для хотя бы default.
Сейчас разницы между switch с breakами и if/else if/else if не должно быть, так как оптимизаторы стараются выжать максимум вне зависимости от исходника.
Как бенчмарк -- одобряю! В обоих случаях, как максимально возможный фоновый поток (то есть реально интегрируемо в приложение) так и отдельно стоящий код (просто выжать максимум).
А если не секрет, какой непротиворечивый юзкейс может быть? (впрочем, один я знаю -- обязательное соответствие определённому, неизменяемому, чек-листу; вообще он уже достаточно весом чтоб делать "надо так надо").
От слова "статья" ссылка отвалилась -- можно повторить?
p.s.: я всегда спрашиваю "а вам зачем?" даже когда есть идеи зачем -- потому, что я ни раз делал что-то, что оказывалось совсем не тем, что требуется; как в том анекдоте про кастрацию...
Прекрасная реализация..! :) Правда, как мне кажется, правильный вопрос на предложенный вопрос должен быть "А вам зачем?!" потому что должно быть незачем... :)
Эквивалент IDAшного "File=>Produce file=>Create dif file", где сохраняется результат редактирования образа в базе данных.
Гидра вообще, если я редактирую через memory -- подсвечивает синеньким что я менял. Если редактирую через ассемблер -- нет. В итоге надо помнить где что менял, либо экспортить весь бинарь и сравнивать потом. И то и то -- неудобственько.
Да, разумеется я заметил дырку (там вначале код, потом дыра под стандартную либу, потом дыра под конфигурацию и в конце немного параметров настройки прошивки)...
Кстати, может, я так же не заметил генерацию патч-файла, как в IDA есть? :) а то заниматься экспортом и диффингом немного устаёт.
И контейнеры позволяют ручную реаллокацию. В отличие от ручного realloc() -- безопасно и аккуартно.
Есть контейнеры, которые уже реализуют варианты кусочно-линейных представлений, есть контейнеры, предоставляющие цельные куски по требованию, есть списки и деревья разных цветов и пород.
Вы правда утверждаете, что ручное выделение, которое написали вы сами, будет работать лучше ручного выделения, которое написал кто-то другой?
Или ваша ручная реализация спокойно поменяет 200 тысяч на 300 миллионов вершин магическим образом, не уходя в никакой лаг?.. Сами же говорите, что нет. Так к чему этот пример был?
Ага. Это ж всегда так работало. "Чтоб неповадно было"
А я б с удовольствием почитал про преобразование одного в другого статью!
Я их видел много кратно. Нет, не просто так. Однако активное использование шаблонов и constexpr -- позволяют оплатить их во время компиляции. unique_ptr делает кучу проверок... Которых не остаётся в скомпилированом коде. Вот простейший синтетический пример: https://godbolt.org/z/ePE68Pob3
Вы вообще знаете, что контейнеры прекрасно работают с аллокаторами? https://en.cppreference.com/w/cpp/container/vector/vector
"Свой аллокатор" это очень полезная штука, не только в геймдеве. Причем код, работающий на контейнерах, прекрасно можно переиспользовать в одном приложении сразу используя с разными аллокаторами без ручного управления.
Да, вам стоит почитать исходники и посмотреть на результат компиляции. Это действительно поучительно.
Действительно есть места, где стандартные контейнеры не подходят, но ответ почему не подходят должен быть осмысленен, оценен и подтвержден -- а не просто проекция страхов на уровне "кто-то там когда-то во времена атлона напел".
А можно не "на глаз" а с примером? Повторюсь: оплата идёт в момент компиляции при аккуратном применении. Тот же unique_ptr буквально компилируется в один указатель, никакой разницы с сырым указателем нет от слова совсем. std::array<X> ничем не отличается от X[], кроме дополнительной безопасности и контроля во время компиляции. Какие именно контейнеры уступают чему именно, можно примеры? А то попахивает что перемножаем яблоки на апельсины и жалуемся что на выходе лампальсины.
А если говорить про "чудесный геймдев"... Я вот вижу насколько блюпринты медленнее си -- и ведь не сказать что все бросили все блюпы нафиг и обходят их за километр, да?
Контейнеры сами по себе не тяжелее сырого указателя. При аккуратном применении, стоимость умного указателя в рантайме ноль.
Равно как и у контейнеров.
Стоимость их оплачена во время компиляции
Однако качество перевода у @PatientZero таки выше.
Для написания этого поста использовался диапазон 4G/LTE, предоставленный T-Mobile US
https://godbolt.org/z/d576zb98n
Когда-то давным давно, когда земля была раскаленным шаром, а C -- макроассемблером на стероидах, switch это был способ задать таблицу переходов в исходнике (а не просто синтаксическим сахаром). Но да, даже тогда, это не было "за одно сравнение", те же проверки на на отрицательные, на больше максимума и так далее необходимы для хотя бы default.
Сейчас разницы между switch с breakами и if/else if/else if не должно быть, так как оптимизаторы стараются выжать максимум вне зависимости от исходника.
Контекст важен, да. В прямом-личном общении я всегда стараюсь узнать как можно больше контекста.
Как бенчмарк -- одобряю! В обоих случаях, как максимально возможный фоновый поток (то есть реально интегрируемо в приложение) так и отдельно стоящий код (просто выжать максимум).
А если не секрет, какой непротиворечивый юзкейс может быть? (впрочем, один я знаю -- обязательное соответствие определённому, неизменяемому, чек-листу; вообще он уже достаточно весом чтоб делать "надо так надо").
От слова "статья" ссылка отвалилась -- можно повторить?
p.s.: я всегда спрашиваю "а вам зачем?" даже когда есть идеи зачем -- потому, что я ни раз делал что-то, что оказывалось совсем не тем, что требуется; как в том анекдоте про кастрацию...
(картинка с троллейбусом)
Прекрасная реализация..! :) Правда, как мне кажется, правильный вопрос на предложенный вопрос должен быть "А вам зачем?!" потому что должно быть незачем... :)
Всё, замержили: https://github.com/NationalSecurityAgency/ghidra/pull/6506
В следующем релизе будет явно, что можно гексы :)
Вскрыть кислотной ванной, лазером прожечь, залить компаундом.
ок, дошло, где ударение в слове. :D
Эквивалент IDAшного "File=>Produce file=>Create dif file", где сохраняется результат редактирования образа в базе данных.
Гидра вообще, если я редактирую через memory -- подсвечивает синеньким что я менял. Если редактирую через ассемблер -- нет. В итоге надо помнить где что менял, либо экспортить весь бинарь и сравнивать потом. И то и то -- неудобственько.
"меньше цены" или "меньше ценности"?
Да, разумеется я заметил дырку (там вначале код, потом дыра под стандартную либу, потом дыра под конфигурацию и в конце немного параметров настройки прошивки)...
Кстати, может, я так же не заметил генерацию патч-файла, как в IDA есть? :) а то заниматься экспортом и диффингом немного устаёт.