Как обработать изменяющиеся структуры данных на обновлении версии программы?

То, что вам нужно, это структуры данных с прямой совместимостью. Есть несколько способов сделать это. Вот низкоуровневый подход.

struct address_book
{
  unsigned int length; // total length of this struct in bytes
  char items[0];
}

где 'items' - это массив переменной длины структуры, который описывает свой собственный размер и тип

struct item
{
  unsigned int size; // how long data[] is
  unsigned int id;   // first name, phone number, picture, ...
  unsigned int type; // string, integer, jpeg, ...
  char data[0];
}

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

Люди, использующие реляционные базы данных, используют огромную концепцию.

Это называется разбиение архитектуры на «логический» и «физический» уровни.

Ваши структуры являются одновременно логическими и физический уровень превратился в нечто, что трудно изменить.

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

Вам не нужно заново изобретать SQL, чтобы добиться этого.

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

Если ваши данные синхронизируются в файловой системе, у вас есть больше работы. Опять же, посмотрите на идею дизайна СУБД.

Не кодируйте простую безмозглую структуру . Создайте «запись», которая сопоставляет имена полей со значениями полей. Это связанный список пар имя-значение. Это легко расширяется, чтобы добавить новые поля или изменить тип данных значения.

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

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

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

если говорить о реальной базе данных, в которой есть метаданные о полях и т. д., то эти рекомендации на самом деле не применимы.

I have handled this in the past, in systems with very limited resources, by doing the translation on the PC as a part of the s/w upgrade process. Can you extract the old values, translate to the new values and then update the in-place db?

For a simplified embedded db I usually don't reference any structs directly, but do put a very light weight API around any parameters. This does allow for you to change the physical structure below the API without impacting the higher level application.

В последнее время я использую кодированный данные. Это формат, который использует BitTorrent. Просто, вы можете легко проверить его визуально, поэтому его легче отлаживать, чем двоичные данные, и он тесно упакован. Я позаимствовал код из высококачественной библиотеки C ++ libtorrent . Для вашей проблемы это так просто, как проверить, существует ли поле, когда вы их прочитаете. А для файла, сжатого с помощью gzip, это так просто:

ogzstream os(meta_path_new.c_str(), ios_base::out | ios_base::trunc);
Bencode map(Bencode::TYPE_MAP);
map.insert_key("url", url.get());
map.insert_key("http", http_code);
os << map;
os.close();

Чтобы прочитать его:

igzstream is(metaf, ios_base::in | ios_base::binary);
is.exceptions(ios::eofbit | ios::failbit | ios::badbit);
try {
   torrent::Bencode b;
   is >> b;
   if( b.has_key("url") )
      d->url = b["url"].as_string();
} catch(...) {
}

Я использовал формат Sun XDR в прошлом, но сейчас предпочитаю его. Также его намного легче читать на других языках, таких как perl, python и т. Д.

Вставьте номер версии в структуру или сделайте так, как это делает Win32, и используйте параметр размера.
если переданная структура не является последней версией, исправьте структуру.

Около 10 лет назад я написал систему, аналогичную описанной выше, для системы сохранения компьютерной игры. Я фактически сохранил данные класса в отдельном файле описания класса, и если я обнаружил несоответствие номера версии, я смогу просмотреть файл описания класса, найти класс, а затем обновить двоичный класс на основе описания. Это, очевидно, требовало, чтобы значения по умолчанию заполнялись в новых записях членов класса. Он работал очень хорошо, и его также можно было использовать для автоматического создания файлов .h и .cpp.

Вы можете посмотреть, как библиотека Boost Serialization решает эту проблему.

Люди, использующие реляционные базы данных, используют огромную концепцию.

Это называется разбиением архитектуры на «логический» и «физический» уровни.

Ваши структуры являются одновременно логическими и физический уровень, смешанный воедино, в вещь, которую трудно изменить.

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

Для этого не нужно изобретать SQL заново.

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

Если ваши данные синхронизируются с файловой системой, у вас есть больше работы. Опять же, посмотрите на идею дизайна СУБД.

Не кодируйте простую безмозглую структуру . Создайте «запись», которая сопоставляет имена полей со значениями полей. Это связанный список пар имя-значение. Это легко расширяется для добавления новых полей или изменения типа данных значения.

Если ваши данные синхронизируются с файловой системой, у вас есть больше работы. Опять же, посмотрите на идею дизайна СУБД.

Не кодируйте простую безмозглую структуру . Создайте «запись», которая сопоставляет имена полей со значениями полей. Это связанный список пар имя-значение. Его легко расширить, добавив новые поля или изменив тип данных значения.

Если ваши данные синхронизируются с файловой системой, у вас есть больше работы. Опять же, посмотрите на идею дизайна СУБД.

Не кодируйте простую безмозглую структуру . Создайте «запись», которая сопоставляет имена полей со значениями полей. Это связанный список пар имя-значение. Его легко расширить, добавив новые поля или изменив тип данных значения.

Я согласен с С.Лоттом в том, что лучшее решение - разделить физический и логический уровни того, что вы пытаетесь сделать. По сути, вы объединяете свой интерфейс и свою реализацию в один объект / структуру, и при этом вы упускаете часть возможностей абстракции.

Однако, если вы должны использовать для этого одну структуру , есть несколько вещей, которые вы можете сделать, чтобы упростить задачу:

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

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

3) Поскольку ваша структура может быть изменяя размеры, не полагайтесь на sizeof (struct myStruct) , чтобы всегда возвращать точные результаты. Если вы последуете пункту 2 выше, то увидите, что должны предполагать, что структура может вырасти больше в будущем. Вызовы sizeof () рассчитываются один раз (во время компиляции). Использование поля «длина структуры» позволяет вам быть уверенным, что, когда вы (например) memcpy структуру, вы копируете всю структуру, включая любые дополнительные поля в конце, о которых вы не знаете.

4) Никогда не удаляйте и не сжимайте поля; если они вам не нужны, оставьте их пустыми. Не меняйте размер существующего поля; если вам нужно больше места, создайте новое поле как «длинную версию» старого поля. Это может привести к проблемам с дублированием данных, поэтому тщательно продумайте структуру и постарайтесь спланировать поля так, чтобы они были достаточно большими, чтобы обеспечить их рост.

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

Несколько встроенных проектов, над которыми я работал, использовали этот метод для изменения структур без нарушения обратной / прямой совместимости. Это работает, но это далеко не самый эффективный метод. Вскоре вы будете тратить пространство на устаревшие / заброшенные поля структуры, дублирующиеся данные, данные, которые хранятся по частям (первое слово здесь, второе слово там) и т. Д. И т. Д. Если вы вынуждены работать в рамках существующей структуры, это может работать на вас. Однако,