C++ и "универсальная сериализаци". Велосипед? - C/C++. Прикладные вопросы

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

Схема работы:

1. Пишем проект на классическом C++, оформляя классы, нуждающиеся в сериализации и динамическом создании вообще, RTTI следующим образом:

// @class[dynamic,serializable]
class SomeClass
{
private:
// @field[serializable]
int x;
// @field[serializable]
std::string name;
// @field[serializable,array]
float *height_map;
// @field[serializable,polymorphic]
SomeOtherClass *parent;
// @field[serializable,polymorphic,array]
SomeOtherClass **childs;
...
public:
// @ctor
SomeClass();
// @meth
void someMethod( ... );
...
};

2. Перед компиляцией программы запускаем специальный парсер, который сделает нам для всех наших модулей новый модуль: rtti.cpp и rtti.h заполнив их всем что для жизни надо.

3. Компилируем весь проект, используя файл rtti и заранее сгенерированные ф-ии из него.

4. Запускаем.

Прошу не придираться к конкретным тегам — это лишь задумка, но ясен пень что это всё пахнет большущим велосипедом, поэтому вопрос ребром:

Встречали ли вы аналогичную схему сериализации для кода на C++ и если да, то где??
На boost::serialize просьба не отсылать — вопрос стоит так как он поставлен.

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

_A_>Встречали ли вы аналогичную схему сериализации для кода на C++ и если да, то где??

Как раз сейчас этим занят

Только информация извлекается не до компиляции, а после (но до компоновки). И не из исходников, а из промежуточных файлов создаваемых компилятором (точно знаю, что это делаете для VC и добрые люди подсказали, что аналогично можно сделать для GCC).

http://www.rsdn.ru/Forum/Message.aspx?mid=1261849 — пункт №4
http://www.rsdn.ru/Forum/Message.aspx?mid=1271651

Здравствуйте, _A_L_X_

Полку "C++ сериализаторов" прибывает. Что не может не радовать

Если дело так пойдет и дальше, нужно будет задумываться о консолидации усилий

Задавая подобный вопрос лучше было воспользоваться поиском по формам "C++" и "C++ прикладные вопросы". Здесь проблемы сериализации регулярно поднимают, в том числе и об оригинальных проектах разсказывают.

Вот, например, несколько тем:
Проект сериализации [просьба высказаться]
Проект сериализации — 2 [просьба высказаться]
Проект сериализации — 3 [просьба высказаться]
[ANN] ObjESSty — еще один проект сериализации
Сериализация
Reflection for C++

Что касается конкретно твоей идеи, то она не нова. Думаю, что все, кто пытались сделать какую-либо систему сериализации для C++, рано или позно приходили к этому варианту (см., например, Re[3]: Reflection for C++: вообще). На первый взгляд она может показаться очень привлекательной. Но есть, правда, парочка неприятностей:

1. Создать нормальный парсер C++, который бы умел парсить сложные C++ конструкции и извлекать при этом какую-то метаинформацию из комментариев -- это, имхо, архисложно. Хотя есть gcc-xml и продвинутые генераторы парсеров (например, Re: Идеальный парсер), но все это, имхо, совсем не просто довести до законченого решения для C++ сериализации/рефлекшена.

2. Применительно к сериализации, C++ синтаксис не позволяет задавать каких-либо атрибутов сериализации. Как, скажем, для XML-сериализации указать, что атрибут Some_Class::my_attr_ должен представляться в виде элемента:

<my_attr value="..." />

а атрибут Another_Class::simple_value_ должен представляться в виде атрибута:

<another_class oid="..." simple_value="..." />

?
Окажется, что все это придется растворять в метаинформации в комментарии к атрибуту. Что приведет к тому, что в C++ коде будут собраны описания для нескольких языков сразу: сам C++ и плюс к нему метаинформация для сериализации. А если комментарии еще используются для документирования (с использованием doxygen-like инструментов), то можно получить вообще серьезную кашу:

class Another_Class
    {
        ...
        /*!
            \brief Уникальный идентификатор.
            
            Формируется при создании объекта и остается неизменным в течении
            всей жизни объекта. Для формирования используется алгоритм [XXX].
            
            \note Поскольку алгоритм [XXX] в нескорых случаях может приводить
            к коллизиям, то используется его модификация использованная в [XXX-2].
            
            @field[serializable]
            @serialization-specific[
                mode: xml
                image-type: attribute
                attribute-name: simple_value
            ]
        */
        Unique_Identifier    unique_value_;
        ...
    };

Если ты считаешь, что смешение нескольких типов описаний в C++ коде -- это нормально, то тогда не обращай на это мое замечание внимания.

И напоследок еще одна ремарка: мне показалось, что твой способ описания в коментариях слишком избыточен. Например, когда класс объявляется сериализуемым, проще по умолчанию считать все атрибуты сериализуемыми. И помечать специальными тегами только те атрибуты, которые не сериализуются (transient-атрибуты). Имхо, так будет проще.

А вообще, имхо, всем, кто собирается делать подобные эксперименты над C++ имеет смысл прочитать: Metaprogramming et al

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

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

E>А вообще, имхо, всем, кто собирается делать подобные эксперименты над C++ имеет смысл прочитать: Metaprogramming et al

Сообщение очень хорошее, но есть одно но — я искрене верю, что у меня получится.
Возможно это глупо и по-детски, но разве нужно ещё что-то, чтобы дело двигалось вперёд?

	От:	_A_L_X_
	Дата:	14.08.05 16:21
	Оценка:

От:	adontz	http://adontz.wordpress.com/
Дата:	14.08.05 16:43
Оценка:

От:	eao197	http://eao197.blogspot.com
Дата:	14.08.05 21:01
Оценка:

От:	adontz	http://adontz.wordpress.com/
Дата:	14.08.05 21:13
Оценка: