Сериализация (как сделать поудобнее)

[Old]

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

Разговор немного о другом. Сериализацией и так будет заниматься сам объект, а вот вместо двух (часто идентичных) операторов << >>, будет один.

[sergek]

Я не прошу реализовывать, вопрос: как пушатся сложные объекты, например, коллекция объектов?

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

Код:

// запись для просмотра списка пользователей
class Ruser_inf : public BoaInterface
{
public:
    Ruser_inf();
    int id_user;
    char user_type;
    bool deny;
    string user_name;
    string firstname;
    string lastname;
    string patronymic;
    string organization;
};
typedef BoaTable<Ruser_inf> User_inf;
BoaDataSet* selUser_info(Bint* sortOrder);

А пушатся члены-данные записи. Вообще, библиотека заточена под реляционную БД, т.е прямоугольные однородные таблицы.
Ну, наверное, можно придумать пример, который не впишется в мою схему. Но хотелось бы конкретики, желательно, из жизни. А вдруг, решаемо...

[Old]

А пушатся члены-данные записи. Вообще, библиотека заточена под реляционную БД, т.е прямоугольные однородные таблицы.

Т.е. есть свой класс коллекция, которая умеет себя сериализовать.

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

Есть любой std::map. Как его сериализовать таблицей, а главное как потом десериализовать?

[ViTech]

От увлекающихся обобщенным программированием я ожидал чего-то типа такого

Код

C++ (Qt)
template <class Stream, class T>
void ReadWrite( Stream & strm, T * data, int mode )
{
 switch (mode)
 ...
 
void MyStruct::ReadWrite( QDataStream & strm, int mode )
{
    ReadWrite(strm, &intPoleMyStruct, mode);
    ...
 

Для определенных задач, когда клиент и сервер обменивается одинаковыми структурами в обе стороны, такой вариант может облегчить жизнь. Для других задач надо иметь в виду такой момент: если клиент отправляет серверу одну структуру типа request, а сервер в ответ другую типа response (и наоборот не будет), то при таком подходе этот вариант не самый лучший. Да, он в два раза уменьшит исходный код сериализации, но и в два раза увеличит конечный (скомпилированный) . Потому что клиенту не нужен read(request) и write(response), а серверу не нужен read(response) и write(request). В этом же варианте при любом значении mode скомпилируется код на чтение и на запись сразу, хоть это и не всем нужно.

Вариант sergek, конечно, хорош, но общий предок - это не совсем честно . С общим предком много чего можно сделать интересного. Можно взять общего предка QObject и практически бед не знать с его metaObject. Правда туда стороннюю произвольную структуру не воткнешь, и вернемся к тому, с чего начали.

[Old]

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

Что то мне подсказывает, что топикстартеру нужна сериализация только на диск.

[alexis031182]

Разговор немного о другом. Сериализацией и так будет заниматься сам объект, а вот вместо двух (часто идентичных) операторов << >>, будет один.

Вариант Igors понятен. Если не сложно, уточните, что делается в буст?

[alexis031182]

Что то мне подсказывает, что топикстартеру нужна сериализация только на диск.

Эта тема - продолжение темы про сериализацию данных, передаваемых через сеть.

[alexis031182]

Для определенных задач, когда клиент и сервер обменивается одинаковыми структурами в обе стороны, такой вариант может облегчить жизнь. Для других задач надо иметь в виду такой момент: если клиент отправляет серверу одну структуру типа request, а сервер в ответ другую типа response (и наоборот не будет), то при таком подходе этот вариант не самый лучший. Да, он в два раза уменьшит исходный код сериализации, но и в два раза увеличит конечный (скомпилированный) . Потому что клиенту не нужен read(request) и write(response), а серверу не нужен read(response) и write(request). В этом же варианте при любом значении mode скомпилируется код на чтение и на запись сразу, хоть это и не всем нужно.

В бинарник попадёт только то, что используется.

[Old]

Если не сложно, уточните, что делается в буст?

Вот ссылка на примеры: http://www.boost.org/doc/libs/1_53_0/libs/serialization/doc/index.html

[alexis031182]

Вот ссылка на примеры: http://www.boost.org/doc/libs/1_53_0/libs/serialization/doc/index.html

Спасибо. Классное решение!

[ViTech]

В бинарник попадёт только то, что используется.

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

[alexis031182]

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

Специализации шаблона функции можно просто вставить, где вместо аргумента Mode этот Mode будет типом, и тогда будет использоваться то, что нужно. Но при этом код будет един для клиента и сервера. А вообще вот в бусте отличная идея заложена на это дело. Лаконичнее наверное не придумаешь.

[ViTech]

Специализации шаблона функции можно просто вставить, где вместо аргумента Mode этот Mode будет типом, и тогда будет использоваться то, что нужно. Но при этом код будет един для клиента и сервера.

Да, можно Mode сделать параметром шаблона, а не функции (тогда шаблоны Igors будут немного по другому выглядеть). При этом Mode должен быть известен в compile-time, что накладывает некоторые ограничения. В частности смотреть, что будет при наследовании, полях-ссылках на другие структуры и т.п.

А вообще вот в бусте отличная идея заложена на это дело. Лаконичнее наверное не придумаешь.

Способ буста хорош, тут не поспоришь. Но это надо буст с собой носить, не всем это нравится. Опять же, должна быть возможность для модификации исходных структур, а если такой возможности нет? Способ QDataStream в этом отношении мне как-то ближе , но нет доступа к защищенным/приватным членам . И как тут не разорваться...  .

[alexis031182]

Да, можно Mode сделать параметром шаблона, а не функции (тогда шаблоны Igors будут немного по другому выглядеть).

Я и имел в виду параметром шаблона функции (специализацию шаблона функции, а не класса). Впрочем, конечно можно и класс привязать.

При этом Mode должен быть известен в compile-time, что накладывает некоторые ограничения.

Да, в compile-time, причём легко число можно сделать типом и тогда пойдёт совсем другая пляска. Не вижу ограничений, просто иной подход.

В частности смотреть, что будет при наследовании, полях-ссылках на другие структуры и т.п.

Это если класс. Но и это обходится через абстрактный интерфейс.

Я лично всегда за compile-time. Меня меньше всего волнует размер бинарника, т.к. он всегда в моём случае даже и близко несопоставим с размерами подключаемых библиотек, какие бы я шаблоны и в каком количестве не использовал. А вот преимущества от compile-time по моему очевидны. Впрочем, дело вкуса, т.к. отладка шаблонов, она, мягко говоря, кошмарна.

Способ буста хорош, тут не поспоришь. Но это надо буст с собой носить, не всем это нравится. Опять же, должна быть возможность для модификации исходных структур, а если такой возможности нет?

Ну конечно всегда надо исходить из условий. Если уж нет возможности подправить в нужное русло исходные типы, то ничего не поделаешь.

Способ QDataStream в этом отношении мне как-то ближе , но нет доступа к защищенным/приватным членам . И как тут не разорваться...  .

Плохо, когда нет системы в коде. Нужно обязательно её создать, иначе будет как минимум беспорядок. Поэтому, если для поддержки принятого в системе подхода требуется чем-то пожертвовать, даже собственными принципами, то лучше это сделать как можно раньше. А вообще конечно, самое трудное - это выбрать систему.

[Bepec]

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

А ещё желательно с примерами в коде

PS заложите, так сказать, правильный подход к сериализации. А то у меня сериализация мозголомная в проекте, вон я тему создавал - наследие драконов прям