Управление изменениями в формате данных на основе памяти

Question

Итак, я использовал компактный тип данных в c ++, и для сохранения из памяти или загрузки из файла нужно просто копировать биты памяти внутрь и наружу.

Однако очевидным недостатком этого являетсячто если вам нужно добавить / удалить элементы в данных, это становится немного грязно.Существуют также проблемы с управлением версиями. Предположим, вы распространяете программу, использующую данные версии A, а затем на следующий день вы создаете версию B, а затем версию C.

Полагаю, это можно решить.используя что-то вроде XML или JSON.Но предположим, что вы не можете сделать это по техническим причинам.

Каков наилучший способ сделать это, кроме необходимости делать разные, если дела и т. Д. (Что было бы довольно некрасиво, я думаю)

Answer 1

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

Answer 2

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

Answer 3

Мы занимаемся этим на моей работе. Это не самое лучшее, но кое-что можно сделать:

• добавить заголовок ко всем файлам, где первое поле - «версия», а второе - «длина». При загрузке вы можете теперь иметь дело со старыми версиями соответствующим образом.

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

Answer 4

Если вы пойдете «по столбцам», то можете добавлять поля по своему усмотрению.

исходная структура старым способом:

struct Person {
  string name;
  int age;
};

vector<Person> People;  // single file for all fields

добавление поля старым способом:

struct Person {
  string name;
  int age;
  string address;  // now must rewrite files on disk
};

новый и улучшенный способ:

namespace People {
  vector<string> name;  // first file
  vector<int> age;      // second file
}

добавление к новому пути:

namespace People {
  vector<string> name;
  vector<int> age;
  vector<string> address;  // add a third file and leave other two alone 
}

Суть в том, что каждое поле является отдельным файлом.Дополнительным преимуществом является то, что пользователю нужно только читать / писать нужные ему поля, поэтому управление версиями становится проще.

Answer 5

Вот как I взломает его. Это «хакерский» подход, но его можно расширить, чтобы сделать его более сложным.

struct file
{
 int32 fileversion;    //different parsers, one for each file version
 int offsetlen;        //length of blocks
 int numblocks;        //number of blocks
 int*  fileoffsets;    //this array has internal offsets, corresponding to blocks
 block* blocklist;     //blocks.
};

struct block
{
  //stuff here of a fixed length
};

Чтобы записать файл с блоками фиксированного размера , алгоритм будет выглядеть примерно так -

write(f.fileversion)
write(f.offsetlen)
write(f.numblocks)
for i in f.blocklist
  write(f.blocklist[i])

и читать -

f.fileversion = read(sizeof(f.fileversion))
f.offsetlen = read(sizeof(f.offsetlen))
f.numblocks = read(sizeof(f.numblocks))
for i in f.numblocks
   f.blocks[i] = read(f.offsetlen)

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