Класс для сериализации CSerializeBase - Исходники

Статья:
Класс для сериализации CSerializeBase

Авторы:
Сабельников Андрей Николаевич

Аннотация:
Вопросы сохранения данных из объектов, так или иначе, возникают у каждого разработчика. В какой-то момент появляется желание “упаковать” все (или не все) данные какого-нибудь объекта и просто сохранить их в файл, или передать по сети и т.п. Это довольно просто сделать для так называемых POD-типов(plain old data) с помощью копирования соответствующих участков памяти. Но если в структуре появляется, к примеру, хотя бы указатель строку, то этот метод совершенно негодится. Приходится определять формат, отлаживать его, документировать, и делать разные другие нехорошие вещи.
Итак, необходим инструмент, с помощью которого можно “упаковывать” любой объект класса С++ в непрерывный кусок памяти. Предлагаю вариант, который, я надеюсь, поможет многим сэкономить время.

Здравствуйте, Сабельников Андрей Николаевич

Андрей, у тебя в статье есть фраза:

Если вас по каким-то причинам не удовлетворяет представленное решение, вы можете написать мне письмо с предложениями и пожеланиями, или посмотреть в сторону других решений, например в сторону boost::serialization или XTL.

Вот если не брать в расчет объем boost-а или политических причин не использования boost-а, то по каким причинам нужно предпочесть твое решение тому же boost::serialization или http://www.s11n.net? Что в CSerializeBase такого уникального, что должно было бы заставить использовать именно CSerializeBase?

Здравствуйте, eao197, Вы писали:

E>Здравствуйте, Сабельников Андрей Николаевич

E>Андрей, у тебя в статье есть фраза:
E>

E>Если вас по каким-то причинам не удовлетворяет представленное решение, вы можете написать мне письмо с предложениями и пожеланиями, или посмотреть в сторону других решений, например в сторону boost::serialization или XTL.

E>Вот если не брать в расчет объем boost-а или политических причин не использования boost-а, то по каким причинам нужно предпочесть твое решение тому же boost::serialization или http://www.s11n.net? Что в CSerializeBase такого уникального, что должно было бы заставить использовать именно CSerializeBase?

Мой велосипед просче чем буст. Легче по весу и внешне другой. Если вы любите разнообразие, то welcome!
Небольшой коментарий: я выложил не для того что б показать что моё решение лучше чем буст — я так не думаю.
Я хотел увидеть критику именно этого подхода и его реализации.

Здравствуйте, <Аноним>, Вы писали:

А>Мой велосипед просче чем буст. Легче по весу и внешне другой. Если вы любите разнообразие, то welcome!

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

Можешь ли ты еще что-нибудь про свое решение сказать, чтобы мне захотелось его скачать и потратить время на изучение?

А>Небольшой коментарий: я выложил не для того что б показать что моё решение лучше чем буст — я так не думаю.
А>Я хотел увидеть критику именно этого подхода и его реализации.

Из критики:

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

Из статьи я не понял, поддерживается ли (и как) наследование не напрямую от CSerializableBase, а от другого сериализуемого класса, уже унаследованного от CSerializableBase.

... << RSDN@Home 1.1.4 stable rev. 510>>

Здравствуйте, eao197, Вы писали:

E>Здравствуйте, <Аноним>, Вы писали:

А>>Мой велосипед просче чем буст. Легче по весу и внешне другой. Если вы любите разнообразие, то welcome!

E>Разнообразие я люблю, даже сам таким разно(безо)бразием занимаюсь. Но вот про "легче" можно говорить, при условии, что он (твой подход) обладает еще какими-то интересными качествами. А вот "внешне другой" -- это не аргумент.

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

E>Можешь ли ты еще что-нибудь про свое решение сказать, чтобы мне захотелось его скачать и потратить время на изучение?

А>>Небольшой коментарий: я выложил не для того что б показать что моё решение лучше чем буст — я так не думаю.
А>>Я хотел увидеть критику именно этого подхода и его реализации.

E>Из критики:

E>Мне не понравилось, что стандартные контейнеры нужно заменять твоими аналогами.
Добавьте макрос SERIALIZE_STL_CONTAINER, если вас смущают мои контейнеры.(единственное — Вам нужно будет для контейнера уметь в компилтайм определить — специализирован он POD типом или наследованным от CSerializableBase).

E>Из статьи я не понял, поддерживается ли (и как) наследование не напрямую от CSerializableBase, а от другого сериализуемого класса, уже унаследованного от CSerializableBase.
Поддерживается. Так как вам это нужно — главное что б открытые члены CSerializableBase были доступны из класса в котором определена карта.

Здравствуйте, <Аноним>, Вы писали:

E>>Разнообразие я люблю, даже сам таким разно(безо)бразием занимаюсь. Но вот про "легче" можно говорить, при условии, что он (твой подход) обладает еще какими-то интересными качествами. А вот "внешне другой" -- это не аргумент.

А>Скажем так — я постарался сделать это настолько простым насколько это было возможно.

А мне казалось, что нужно делать максимально функциональным и удобным.

А>Сериализация в стиле минимализма — она никогда не станет второй ObjESSty

Вот и славненько. Можно вздохнуть свободно

E>>Мне не понравилось, что стандартные контейнеры нужно заменять твоими аналогами.
А>Добавьте макрос SERIALIZE_STL_CONTAINER, если вас смущают мои контейнеры.(единственное — Вам нужно будет для контейнера уметь в компилтайм определить — специализирован он POD типом или наследованным от CSerializableBase).

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

E>>Из статьи я не понял, поддерживается ли (и как) наследование не напрямую от CSerializableBase, а от другого сериализуемого класса, уже унаследованного от CSerializableBase.
А>Поддерживается. Так как вам это нужно — главное что б открытые члены CSerializableBase были доступны из класса в котором определена карта.

Было бы хорошо, если бы это в статье было показано.

Кстати, а полиморфные атрибуты можно сериализовать? Скажем есть A, производный от CSerializableBase. И есть B, атрибутом которого является A*. И этот указатель может указывать на любой производный от A сериализуемый класс.

... << RSDN@Home 1.1.4 stable rev. 510>>

Здравствуйте, eao197, Вы писали:

E>Здравствуйте, <Аноним>, Вы писали:

E>>>Разнообразие я люблю, даже сам таким разно(безо)бразием занимаюсь. Но вот про "легче" можно говорить, при условии, что он (твой подход) обладает еще какими-то интересными качествами. А вот "внешне другой" -- это не аргумент.

А>>Скажем так — я постарался сделать это настолько простым насколько это было возможно.

E>А мне казалось, что нужно делать максимально функциональным и удобным.

А>>Сериализация в стиле минимализма — она никогда не станет второй ObjESSty

E>Вот и славненько. Можно вздохнуть свободно

E>

E>>>Мне не понравилось, что стандартные контейнеры нужно заменять твоими аналогами.
А>>Добавьте макрос SERIALIZE_STL_CONTAINER, если вас смущают мои контейнеры.(единственное — Вам нужно будет для контейнера уметь в компилтайм определить — специализирован он POD типом или наследованным от CSerializableBase).

E>Вот этого не понял. Мне что-то нужно? Мне нужно указать, что контейнер должен быть сериализован. А все остальное должна определять система сериализации.
Вам нужно написать две функции:

    template<class ContainerType>
    int SerializeStlContainer(const ContainerType& refContainer, CSerializedUpContainer* pObjectToSerialize);
    template<class ContainerType>
    int UnSerializeStlContainer(ContainerType& refContainer, CSerializedUpContainer* pObjectToSerialize);

и залепить эти функции в новый макрос SERIALIZE_STL_CONTAINER(). Каждая функция будет занимать 6-7 строк (в одном случае перебрать контейнер в цикле, в другом заполнить его).
Но имейте в виду, что код, который будет работать для листа и вектора, скорее всего не будет работать для map — т.к. вставка в них происходит совершенно разыми способами.

E>>>Из статьи я не понял, поддерживается ли (и как) наследование не напрямую от CSerializableBase, а от другого сериализуемого класса, уже унаследованного от CSerializableBase.
А>>Поддерживается. Так как вам это нужно — главное что б открытые члены CSerializableBase были доступны из класса в котором определена карта.

E>Было бы хорошо, если бы это в статье было показано.

E>Кстати, а полиморфные атрибуты можно сериализовать? Скажем есть A, производный от CSerializableBase. И есть B, атрибутом которого является A*. И этот указатель может указывать на любой производный от A сериализуемый класс.
Абсалютна адназначна ДА!
CSerializableBase наследован от интерфейса ISerialize. Именно этот интерфейс ждёт SERIALIZE_T() (точнее не он а пара функций которые за ним стоят). Объект может быть на самом деле чем угодно — но он ДОЛЖЕН реализовывать этот интерфейс, если хочет учавствовать в карте сериализации.

Здравствуйте, <Аноним>

Возвращаясь к конструктивной критике: вот эти два твоих пояснения (да еще бы с примерами) хорошо бы иметь прямо в статье.

E>>Вот этого не понял. Мне что-то нужно? Мне нужно указать, что контейнер должен быть сериализован. А все остальное должна определять система сериализации.
А>Вам нужно написать две функции:
А>

А>    template<class ContainerType>
А>    int SerializeStlContainer(const ContainerType& refContainer, CSerializedUpContainer* pObjectToSerialize);
А>    template<class ContainerType>
А>    int UnSerializeStlContainer(ContainerType& refContainer, CSerializedUpContainer* pObjectToSerialize);
А>

А> и залепить эти функции в новый макрос SERIALIZE_STL_CONTAINER(). Каждая функция будет занимать 6-7 строк (в одном случае перебрать контейнер в цикле, в другом заполнить его).
А>Но имейте в виду, что код, который будет работать для листа и вектора, скорее всего не будет работать для map — т.к. вставка в них происходит совершенно разыми способами.

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

E>>>>Из статьи я не понял, поддерживается ли (и как) наследование не напрямую от CSerializableBase, а от другого сериализуемого класса, уже унаследованного от CSerializableBase.
А>>>Поддерживается. Так как вам это нужно — главное что б открытые члены CSerializableBase были доступны из класса в котором определена карта.

E>>Было бы хорошо, если бы это в статье было показано.

E>>Кстати, а полиморфные атрибуты можно сериализовать? Скажем есть A, производный от CSerializableBase. И есть B, атрибутом которого является A*. И этот указатель может указывать на любой производный от A сериализуемый класс.
А>Абсалютна адназначна ДА!
А>CSerializableBase наследован от интерфейса ISerialize. Именно этот интерфейс ждёт SERIALIZE_T() (точнее не он а пара функций которые за ним стоят). Объект может быть на самом деле чем угодно — но он ДОЛЖЕН реализовывать этот интерфейс, если хочет учавствовать в карте сериализации.

Вот это бы в статье и показать.

... << RSDN@Home 1.1.4 stable rev. 510>>

Здравствуйте, eao197, Вы писали:

E>Здравствуйте, <Аноним>

E>Возвращаясь к конструктивной критике: вот эти два твоих пояснения (да еще бы с примерами) хорошо бы иметь прямо в статье.

E>>>Вот этого не понял. Мне что-то нужно? Мне нужно указать, что контейнер должен быть сериализован. А все остальное должна определять система сериализации.
А>>Вам нужно написать две функции:
А>>

А>>    template<class ContainerType>
А>>    int SerializeStlContainer(const ContainerType& refContainer, CSerializedUpContainer* pObjectToSerialize);
А>>    template<class ContainerType>
А>>    int UnSerializeStlContainer(ContainerType& refContainer, CSerializedUpContainer* pObjectToSerialize);
А>>

А>> и залепить эти функции в новый макрос SERIALIZE_STL_CONTAINER(). Каждая функция будет занимать 6-7 строк (в одном случае перебрать контейнер в цикле, в другом заполнить его).
А>>Но имейте в виду, что код, который будет работать для листа и вектора, скорее всего не будет работать для map — т.к. вставка в них происходит совершенно разыми способами.

E>Вообще-то говоря, это скорее отталкивает от желания использовать CSerializableBase. Мало того, что карту атрибутов прописывать нужно, так еще и адаптеры к контейнерам делать.
Мало того что карту атрибутов описывать надо ???!!!
Дорогой мой, но попилуйте, а как же без этого ?????!
А вот у вас имеется для этого даже целый какой-то специальный язык.

Основная идея в ObjESSty -- это необходимость описания схемы данных на специальном языке и объявление сериализуемых типов производными от специального класса oess_1::stdsn::serializable_t. Все остальное -- задача ObjESSty. По описанию схемы данных автоматически генерируется вспомогательный код, который и выполняет сериализацию/десериализацию.

Согласитесь, уже после прочтения этой фразу ну как-то неинтересно становится — какой-то свой язык...

Если не описывать каким-нибудь образом состав атрибутов — то будет как минимум неочень гибкое решение. (если оно вообще возможно нормальными способами). Например, если я нехочу сериализовывать непременно все члены класса, а только те которые кончаются на букву "w"?!

Вот поэтому у меня использована карта.(помойму это большая приятность чем свой собственный язык).

Что касается STL контейнеров: можно сделать поддержку для ЛЮБЫХ типов, будь то stl или boost или ещё какая-нибудь библиотека.
Делается это, как написанно в статье, двумя способами — или свой макрос и пара своих функций, или наследованием.
Первый вариант для Вас, как я понимаю, предпочтительней. Я согласен с тем что поддержки stl контейнеров нехватает и постараюсь сделать и отладить её в ближайшие выходные.

E>>>>>Из статьи я не понял, поддерживается ли (и как) наследование не напрямую от CSerializableBase, а от другого сериализуемого класса, уже унаследованного от CSerializableBase.
А>>>>Поддерживается. Так как вам это нужно — главное что б открытые члены CSerializableBase были доступны из класса в котором определена карта.

E>>>Было бы хорошо, если бы это в статье было показано.

E>>>Кстати, а полиморфные атрибуты можно сериализовать? Скажем есть A, производный от CSerializableBase. И есть B, атрибутом которого является A*. И этот указатель может указывать на любой производный от A сериализуемый класс.
А>>Абсалютна адназначна ДА!
А>>CSerializableBase наследован от интерфейса ISerialize. Именно этот интерфейс ждёт SERIALIZE_T() (точнее не он а пара функций которые за ним стоят). Объект может быть на самом деле чем угодно — но он ДОЛЖЕН реализовывать этот интерфейс, если хочет учавствовать в карте сериализации.

E>Вот это бы в статье и показать.

Здравствуйте, <Аноним>, Вы писали:

E>>Вообще-то говоря, это скорее отталкивает от желания использовать CSerializableBase. Мало того, что карту атрибутов прописывать нужно, так еще и адаптеры к контейнерам делать.
А>Мало того что карту атрибутов описывать надо ???!!!
А>Дорогой мой, но попилуйте, а как же без этого ?????!

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

А>Согласитесь, уже после прочтения этой фразу ну как-то неинтересно становится — какой-то свой язык...

Не соглашусь

Язык позволяет делать описания, которые на макросах сделать или очень тяжело, или невозможно. Например, опциональные атрибуты или расширения объектов.

А как на счет множественного наследования. И виртуального наследования?

... << RSDN@Home 1.1.4 stable rev. 510>>

Здравствуйте, eao197, Вы писали:

E>Здравствуйте, <Аноним>, Вы писали:

E>>>Вообще-то говоря, это скорее отталкивает от желания использовать CSerializableBase. Мало того, что карту атрибутов прописывать нужно, так еще и адаптеры к контейнерам делать.
А>>Мало того что карту атрибутов описывать надо ???!!!
А>>Дорогой мой, но попилуйте, а как же без этого ?????!

Вы пишете:
E>Так ведь я против карты атрибутов и не возражаю.
А потом говорите:
>Просто говорю, что написание карты атрибутов вручную (точно как и отдельное описание на DDL) -- это уже лишняя работа, череватая, к тому же ошибками, как практика показала. Мне не навится, что в дополнение к ней еще что-то нужно делать.

Таки я вас непонял...что вы хотели сказать ? Вы за или Вы против ?
Если вы всётаки против то

Если не описывать каким-нибудь образом состав атрибутов — то будет как минимум неочень гибкое решение. (если оно вообще возможно нормальными способами). Например, если я нехочу сериализовывать непременно все члены класса, а только те которые кончаются на букву "w"?!

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

А>>Согласитесь, уже после прочтения этой фразу ну как-то неинтересно становится — какой-то свой язык...

E>Не соглашусь

E>Язык позволяет делать описания, которые на макросах сделать или очень тяжело, или невозможно. Например, опциональные атрибуты или расширения объектов.

E>А как на счет множественного наследования. И виртуального наследования?
Вероятно вы намекаете на проблемы, которые могут появится из-за одного общего базового класса. (поправьте меня если я неправильно Вас понял). Имеет место быть.
Можно функционал CSerializeBase реализовать статическими функциями. Функции

    int SerializeT(ISerialize* pObject, CSerializedDownContainer* pObjectToSerialize);
    int UnSerializeT(ISerialize* pObject, CSerializedUpContainer* pObjectToSerialize);

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

    virtual void OnPreSerialize(){}
    virtual void OnEndSerialize(){}
    virtual void OnPreUnSerialize(){}
    virtual void OnEndUnSerialize(){}

нужно будет точно так же их реализовать в своём классе и получать или через абстрактный интерфейс или как шаблонные вызовы.

Я понимаю Евгений, вы проделали колосальную работу в ObjESSty. Но я не ставил себе тех задач которые видимо стояли у вас.(никаких опциональных атрибутов и расширеинй объектов не требуется).А если они потребуются, они будут сделанны уровнем абстракции уже чуть ниже, обарачивая функционал библиотеки о которой мы говорим.

Здравствуйте, <Аноним>, Вы писали:

А>Вы пишете:
E>>Так ведь я против карты атрибутов и не возражаю.
А>А потом говорите:
>>Просто говорю, что написание карты атрибутов вручную (точно как и отдельное описание на DDL) -- это уже лишняя работа, череватая, к тому же ошибками, как практика показала. Мне не навится, что в дополнение к ней еще что-то нужно делать.

А>Таки я вас непонял...что вы хотели сказать ? Вы за или Вы против ?

Я просто говорю, что поскольку в C++ нет подробной RTTI информации, то выбор идет либо между описанием на макросах или с помощью какого-то языка (или расширения C++ с какими-то препроцессорами, как в Qt). От этого никуда не денешься. Но, согласитесь, по сравнению с той же Java или C# у C++ программиста появляется лишняя работа. И я за то, чтобы эту лишнюю работу минимизировать.
Ты выбрал карту атрибутов. Ok. Пусть она будет. Но хорошо бы, чтобы кроме этой карты ничего больше от программиста не требовалось.

E>>А как на счет множественного наследования. И виртуального наследования?
А>Вероятно вы намекаете на проблемы, которые могут появится из-за одного общего базового класса. (поправьте меня если я неправильно Вас понял). Имеет место быть.

Да я не намекаю. Просто спрашиваю. Поскольку из статьи этого не видно.

А>Я понимаю Евгений, вы проделали колосальную работу в ObjESSty.

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

... << RSDN@Home 1.1.4 stable rev. 510>>

странно, зачем наследоватся от специалного класса?

Здравствуйте, Аноним, Вы писали:

А>странно, зачем наследоватся от специалного класса?
Теперь незачем

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

	От:	Сабельников Андрей Николаевич
	Дата:	19.03.05 07:28
	Оценка:	70 (3)

От:	eao197	http://eao197.blogspot.com
Дата:	07.07.05 15:56
Оценка:

	От:	Аноним
	Дата:	08.07.05 09:46
	Оценка:

От:	eao197	http://eao197.blogspot.com
Дата:	08.07.05 10:11
Оценка:

	От:	Аноним
	Дата:	08.07.05 11:44
	Оценка: