С
Size: a a a
2020 June 04
СВ
Друзья, а есть чат по СИ?
2020 June 05
DS
Я уже не помню точных деталей. Кажется, там было что-то вроде индекса в виде
unordered_map<string_view, size_t> который указывал внутрь контейнера с данными OurSpecialContainer<struct{ string, ... }>. OurSpecialContainer при вставке мог вызвать перемещение элементов. Вся работа по поддержанию индекса и данных была в одной функции, но про ресайз забыли. На самом деле OurSpecialContainer ближе к (hash) map, чем к вектору, но поверх него строился второй индекс.Весело ещё наверное что при перемещении view протухали только для маленьких строк благодаря SSO.
OS
что, если память унифицированная? На некоторых системах (CUDA) можно прозрачно делать на указателях деревья на хосте и использовать на девайсе (которое за PCI)
это я знаю. меня скорее интересовало какие гарантии я могу ожидать по расположению структур данных в памяти, если приложения которыё с этими структурами работают собираются из разных кодовых баз
OS
И вот еще вопрос, если структура создана другим приложением, как мое приложение будет знать о времени жизни обьекта в этой памяти. Я ведь буду делать reinterpret_cast сырых байт в структуру
АВ
Никак
OS
Ну да, я подозреваю что пока нет bit_cast это будет УБ
AT
Если структура - standard layout, то почему обязательно ub?
OS
Потому что я создаю обьект из ничего? Стандартный layout ничего ведь не говорит о времени жизни обьектов
AT
Если из массива char, std::byte, то вроде бы норм
AT
а деструктор у вас тривиальный?
OS
а деструктор у вас тривиальный?
вот появляется новое требование. Нужен ли тривиальный деструктор?
AT
если пересылается пакет по сети, то он тоже как бы неоткуда, но жить как-то можно