#c #boost #boost-serialization #boost-variant
#c #повышение #boost-сериализация #boost-variant
Вопрос:
Я использую boost::variant и boost::serialize в своем приложении. Модуль сериализации имеет встроенную поддержку сериализации вариантов, поэтому:
boost::variant<int,double> u(3.14);
// Do something with u;
// Serialize
oa << u;
работает. Однако моя проблема в том, что сериализация не является надежной. В зависимости от того, как компилируется мое приложение, элементы варианта могут меняться. В настоящее время модуль сериализации, по-видимому, просто внедряет индекс ‘активного’ типа варианта; что является проблемой, если вариант изменен, скажем, на boost::variant<double,string> .
Кто-нибудь может предложить способы улучшения этого, чтобы сериализация / несериализация работала так, чтобы сериализованный тип был параметром шаблона boost::variant . (Таким образом, в приведенном выше случае boost::variant<int,double> u(3.14) может быть не сериализован в boost::variant<double,std::string> . Я понимаю, что это может потребовать от меня предоставления дополнительной информации, такой как строковая форма типа.
Комментарии:
1. Почему вы хотели бы изменить элементы варианта? Обычно вы не хотите, чтобы спецификации вашего формата файла менялись подобным образом.
2. Однако обычно я бы согласился, что сама программа представляет собой численное моделирование. Класс simulation сильно шаблонизирован, существует несколько миллионов возможных комбинаций. Очевидно, что я не могу создать экземпляр всех из них в исполняемый файл. Учитывая, что вся моя пользовательская база самокомпилируется, разумно использовать вариант для хранения поддерживаемых экземпляров.
Ответ №1:
Как будет работать готовый механизм для такой вещи? Например, что он должен делать, если вы изменили boost::variant<int,double> на boost::variant<int,std::string> и больше не можете удерживать double? Создать исключение?
Если вы хотите что-то подобное, я бы предположил, что вам придется написать это самостоятельно, чтобы охватить случаи, которые вы ожидаете, и соответствовать вашему определению «надежного».
Вы также можете встроить некоторую логику обновления файлов … например, каждая версия N вашей программы хранит около старых копий определений структур для (N-1, N-2 …), так что вы можете писать процедуры, которые могут быть использованы для предоставления возможности обновлять старые файлы, с которыми она сталкивается.
Но на самом деле, лучше всего с первого раза максимально корректировать форматы файлов, прежде чем выпускать программу на волю! Особенно данные, кодирующие намерения пользователя (производные структуры, которые фактически являются просто кэшами, могут быть удалены и пересчитаны заново, если версия их не распознает).