Аннотация:
Вопросы сохранения данных из объектов, так или иначе, возникают у каждого разработчика. В какой-то момент появляется желание “упаковать” все (или не все) данные какого-нибудь объекта и просто сохранить их в файл, или передать по сети и т.п. Это довольно просто сделать для так называемых POD-типов(plain old data) с помощью копирования соответствующих участков памяти. Но если в структуре появляется, к примеру, хотя бы указатель строку, то этот метод совершенно негодится. Приходится определять формат, отлаживать его, документировать, и делать разные другие нехорошие вещи.
Итак, необходим инструмент, с помощью которого можно “упаковывать” любой объект класса С++ в непрерывный кусок памяти. Предлагаю вариант, который, я надеюсь, поможет многим сэкономить время.
Если вас по каким-то причинам не удовлетворяет представленное решение, вы можете написать мне письмо с предложениями и пожеланиями, или посмотреть в сторону других решений, например в сторону boost::serialization или XTL.
Вот если не брать в расчет объем boost-а или политических причин не использования boost-а, то по каким причинам нужно предпочесть твое решение тому же boost::serialization или http://www.s11n.net? Что в CSerializeBase такого уникального, что должно было бы заставить использовать именно CSerializeBase?
SObjectizer: <микро>Агентно-ориентированное программирование на C++.
Re[2]: Класс для сериализации CSerializeBase
От:
Аноним
Дата:
08.07.05 09:46
Оценка:
Здравствуйте, 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>>
SObjectizer: <микро>Агентно-ориентированное программирование на C++.
Re[4]: Класс для сериализации CSerializeBase
От:
Аноним
Дата:
08.07.05 11:44
Оценка:
Здравствуйте, 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>>
SObjectizer: <микро>Агентно-ориентированное программирование на C++.
Re[6]: Класс для сериализации CSerializeBase
От:
Аноним
Дата:
08.07.05 12:36
Оценка:
Здравствуйте, 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>>
SObjectizer: <микро>Агентно-ориентированное программирование на C++.
Re[8]: Класс для сериализации CSerializeBase
От:
Аноним
Дата:
08.07.05 13:06
Оценка:
Здравствуйте, 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>>
SObjectizer: <микро>Агентно-ориентированное программирование на C++.
Re[10]: Класс для сериализации CSerializeBase
От:
Аноним
Дата:
08.07.05 13:44
Оценка:
Здравствуйте, eao197, Вы писали:
E>Здравствуйте, <Аноним>, Вы писали:
E>>>Вообще-то говоря, это скорее отталкивает от желания использовать CSerializableBase. Мало того, что карту атрибутов прописывать нужно, так еще и адаптеры к контейнерам делать. А>>Мало того что карту атрибутов описывать надо ???!!! А>>Дорогой мой, но попилуйте, а как же без этого ?????!
Вы пишете: E>Так ведь я против карты атрибутов и не возражаю.
А потом говорите: >Просто говорю, что написание карты атрибутов вручную (точно как и отдельное описание на DDL) -- это уже лишняя работа, череватая, к тому же ошибками, как практика показала. Мне не навится, что в дополнение к ней еще что-то нужно делать.
Таки я вас непонял...что вы хотели сказать ? Вы за или Вы против ?
Если вы всётаки против то
Если не описывать каким-нибудь образом состав атрибутов — то будет как минимум неочень гибкое решение. (если оно вообще возможно нормальными способами). Например, если я нехочу сериализовывать непременно все члены класса, а только те которые кончаются на букву "w"?!
И гораздо проще написать карту, чум свой язык для этого изобретать.
А>>Согласитесь, уже после прочтения этой фразу ну как-то неинтересно становится — какой-то свой язык...
E>Не соглашусь E>Язык позволяет делать описания, которые на макросах сделать или очень тяжело, или невозможно. Например, опциональные атрибуты или расширения объектов.
E>А как на счет множественного наследования. И виртуального наследования?
Вероятно вы намекаете на проблемы, которые могут появится из-за одного общего базового класса. (поправьте меня если я неправильно Вас понял). Имеет место быть.
Можно функционал CSerializeBase реализовать статическими функциями. Функции
int SerializeT(ISerialize* pObject, CSerializedDownContainer* pObjectToSerialize);
int UnSerializeT(ISerialize* pObject, CSerializedUpContainer* pObjectToSerialize);
сделать шаблонными — вместо интерфейса ISerialize шаблонный тип, который обязательно должен иметь соответствующие функции.
Тогда наследоваться будет ненадо.
Если мы захотим получать колбеки
нужно будет точно так же их реализовать в своём классе и получать или через абстрактный интерфейс или как шаблонные вызовы.
Я понимаю Евгений, вы проделали колосальную работу в ObjESSty. Но я не ставил себе тех задач которые видимо стояли у вас.(никаких опциональных атрибутов и расширеинй объектов не требуется).А если они потребуются, они будут сделанны уровнем абстракции уже чуть ниже, обарачивая функционал библиотеки о которой мы говорим.
Здравствуйте, <Аноним>, Вы писали:
А>Вы пишете: E>>Так ведь я против карты атрибутов и не возражаю. А>А потом говорите: >>Просто говорю, что написание карты атрибутов вручную (точно как и отдельное описание на DDL) -- это уже лишняя работа, череватая, к тому же ошибками, как практика показала. Мне не навится, что в дополнение к ней еще что-то нужно делать.
А>Таки я вас непонял...что вы хотели сказать ? Вы за или Вы против ?
Я просто говорю, что поскольку в C++ нет подробной RTTI информации, то выбор идет либо между описанием на макросах или с помощью какого-то языка (или расширения C++ с какими-то препроцессорами, как в Qt). От этого никуда не денешься. Но, согласитесь, по сравнению с той же Java или C# у C++ программиста появляется лишняя работа. И я за то, чтобы эту лишнюю работу минимизировать.
Ты выбрал карту атрибутов. Ok. Пусть она будет. Но хорошо бы, чтобы кроме этой карты ничего больше от программиста не требовалось.
E>>А как на счет множественного наследования. И виртуального наследования? А>Вероятно вы намекаете на проблемы, которые могут появится из-за одного общего базового класса. (поправьте меня если я неправильно Вас понял). Имеет место быть.
Да я не намекаю. Просто спрашиваю. Поскольку из статьи этого не видно.
А>Я понимаю Евгений, вы проделали колосальную работу в ObjESSty.
Да нет, речь ведь не обо мне. Ты же сам хотел критики. Так вот посмотри, сколько вопросов я тебе задал. Можешь вопринимать это как критику того, что в статье они не были раскрыты. Если ты в следующей версии статьи их раскроешь, возможно привлекательность твоего решения для кого-то станет гораздо выше.
... << RSDN@Home 1.1.4 stable rev. 510>>
SObjectizer: <микро>Агентно-ориентированное программирование на C++.
Re: Класс для сериализации CSerializeBase
От:
Аноним
Дата:
14.06.06 17:16
Оценка:
странно, зачем наследоватся от специалного класса?
Re[2]: Класс для сериализации CSerializeBase
От:
Аноним
Дата:
15.06.06 06:35
Оценка:
Здравствуйте, Аноним, Вы писали:
А>странно, зачем наследоватся от специалного класса?
Теперь незачем Вышла новая
версия статьи, в которой я описал обновлённый подход, используемый уже почти год. К сожалению на сайте пока только аннотация, сама статья в журнале, а на веб появится позже.