живые объекты С++, которые живут в файлах с отображением памяти?

Идея состоит в том, что вы постоянно сериализуете все или часть состояния вашей программы в файл, обращаясь к этому файлу через отображение памяти. Это потребует от вас отсутствия обычных указателей, потому что указатели действительны только до тех пор, пока длится ваш процесс. Вместо этого вам нужно сохранить смещения от начала отображения, чтобы при перезапуске программы и переназначении файла вы могли продолжить работу с ним. Преимущество этой схемы в том, что у вас нет отдельной сериализации, что означает, что у вас нет дополнительного кода для этого, и вам не нужно сохранять все состояние сразу - вместо этого ваше (все или большая часть) состояние программы постоянно поддерживается файлом.

Вы бы использовали новое размещение либо напрямую, либо через настраиваемые распределители.

Посмотрите EASTL для реализации (подмножество) STL, специально предназначенная для хорошей работы с пользовательскими схемами распределения (например, требуется для игр, работающих на встроенных системах или игровых консолях).

Бесплатное подмножество EASTL находится здесь:

• http://gpl.ea.com/
• клон на https://github.com/paulhodge/EASTL

Мы используем в течение многих лет то, что мы называем «относительными указателями», что является своего рода умным указателем. Он по своей сути нестандартен, но хорошо работает на большинстве платформ. Он устроен так:

template<class T>
class rptr
{
    size_t offset;
public:
    T* operator->() { return reinterpret_cast<T*>(reinterpret_cast<char*>(this)+offset); }
};

Для этого требуется, чтобы все объекты хранились в одной и той же общей памяти (которая также может быть картой файла). Это также обычно требует, чтобы мы хранили там только наши собственные совместимые типы, а также писали собственные распределители для управления этой памятью.

Чтобы всегда иметь непротиворечивые данные, мы используем моментальные снимки с помощью трюков COW mmap (которые работают в пользовательском пространстве на Linux, не знаю о других ОС).

С большим переходом на 64-битную версию мы также иногда просто используем фиксированные отображения, поскольку относительные указатели несут некоторые накладные расходы во время выполнения. Имея обычно 48-битное адресное пространство, мы выбрали зарезервированную область памяти для наших приложений, на которую мы всегда сопоставляем такой файл.

Это напоминает мне о файловой системе, которую я придумал, чтобы загружать файлы уровня компакт-диска за удивительно короткое время (это улучшило время загрузки с 10 секунд до почти мгновенного), и она также работает на носителях, отличных от компакт-дисков. Он состоял из трех версий класса для переноса функций файлового ввода-вывода с одинаковым интерфейсом:

class IFile
{
public:
  IFile (class FileSystem &owner);
  virtual Seek (...);
  virtual Read (...);
  virtual GetFilePosition ();
};

и дополнительный класс:

class FileSystem
{
public:
  BeginStreaming (filename);
  EndStreaming ();
  IFile *CreateFile ();
};

и вы бы написали код загрузки, например:

void LoadLevel (levelname)
{
  FileSystem fs;
  fs.BeginStreaming (levelname);
  IFile *file = fs.CreateFile (level_map_name);
  ReadLevelMap (fs, file);
  delete file;
  fs.EndStreaming ();
}

void ReadLevelMap (FileSystem &fs, IFile *file)
{
  read some data from fs
  get names of other files to load (like textures, object definitions, etc...)
  for each texture file
  {
    IFile *texture_file = fs.CreateFile (some other file name)
    CreateTexture (texture_file);
    delete texture_file;
  }
}

Тогда у вас будет три режима работы: режим отладки, режим сборки потокового файла и режим выпуска.

В каждом режиме объект FileSystem будет создавать разные объекты IFile.

В режиме отладки объект IFile просто обертывает стандартные функции ввода-вывода.

При построении потокового файла объект IFile также обертывал стандартный ввод-вывод, но имел дополнительные функции записи в потоковый файл (владелец файловой системы открывал потоковый файл) каждого прочитанного байта и записи возвращаемого значения любых запросов позиции указателя файла. (поэтому, если что-то нужно знать размер файла, эта информация записывается в файл потока). Это как бы объединяет различные файлы в один большой файл, но только те данные, которые были фактически прочитаны.

В режиме выпуска создается IFile, который не открывает файлы и не выполняет поиск в файлах, а просто считывает из потокового файла (открытого владельцем объекта FileSystem).

Это означает, что в режиме деблокирования все данные считываются за одну последовательную серию операций чтения (ОС хорошо буферизует их), а не за множество операций поиска и чтения. Это идеально подходит для компакт-дисков, где время поиска очень медленное. Излишне говорить, что это было разработано для консольной системы на основе компакт-диска.

Побочным эффектом является то, что данные удаляются из ненужных метаданных, которые обычно пропускаются.

У него есть недостатки - все данные для уровня находятся в одном файле. Они могут быть довольно большими, и данные не могут быть разделены между файлами, если у вас есть набор текстур, скажем, общих для двух или более уровней, данные будут дублироваться в каждом файле потока. Кроме того, процесс загрузки должен быть одинаковым каждый раз при загрузке данных, вы не можете условно пропускать или добавлять элементы на уровень.

Как указывает Кармак, во многих играх (и других приложениях) загрузочный код структурирован как множество мелких операций чтения и распределения.

Вместо этого вы делаете один fread (или эквивалент), например, файл уровня в память, а затем просто исправляете указатели.