Здравствуйте, 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>Вот это бы в статье и показать.