some_class ob;
  archive.put("xml_tag_for_object", ob);

derived::serialize(archive& arc)
{
  // либо так (в более примитивных подходах, требующих, чтобы функция сериализации была членом)
  // нам это не подходит, далее речь только о втором случае
  base::serialize(arc);       
 
  // либо так (в более продвинутых, вот это и хотим повторить) 
  arc.put(static_cast<base&>(*this));  // либо аналог: arc << static_cast<base&>(*this);
}

derived::serialize(archive& arc)
{
  arc.put("????" /* какой тэг сюда написать???*/,  static_cast<base&>(*this));
}

<tag_for_the_derived>
  <nasty_tag1>
     base1 members
  </nasty_tag1>
  <nasty_tag2>
     base2 members
  </nasty_tag2>
  derived members
<tag_for_the_derived>

А>derived::serialize(archive& arc)
А>{
А>  // либо так (в более примитивных подходах, требующих, чтобы функция сериализации была членом)
А>  // нам это не подходит, далее речь только о втором случае
А>  base::serialize(arc);       
А> 
А>  // либо так (в более продвинутых, вот это и хотим повторить) 
А>  arc.put(static_cast<base&>(*this));  // либо аналог: arc << static_cast<base&>(*this);
А>}
А>

А>derived::serialize(archive& arc)
А>{
А>  arc.put("????" /* какой тэг сюда написать???*/,  static_cast<base&>(*this));
А>}
А>

А><tag_for_the_derived>
А>  <nasty_tag1>
А>     base1 members
А>  </nasty_tag1>
А>  <nasty_tag2>
А>     base2 members
А>  </nasty_tag2>
А>  derived members
А><tag_for_the_derived>
А>

class Base
{
public:
    void Serialize(Archive& a)
    {
        a.OpenTag(MyNameIs());
        DoSerialize(a);
        a.CloseTag(MyNameIs());
    }

protected:
    // определяем реализацию в наследниках
    virtual string MyNameIs() const = 0;
    virtual void DoSerialize(Archive& a) = 0;
};

А>derived::serialize(archive& arc)
А>{
А>  arc.put("????" /* какой тэг сюда написать???*/,  static_cast<base&>(*this));
А>}
А>

    Archive::put(const ISerializable & ob)

<age>30</age>
<salary>666.66</salary>

<int>30</int>
<double>666.66</doble>

А>Я думал об этом, но это (опять-таки, имхо ), неправильно. Почему? Сформулирую две предпосылки:

<age>>30</age>
А><salary>666.66</salary>
А>

<int>>30</int>
А><double>666.66</doble>
А>

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

А>Да это мне и с точки зрения философии кажется более правильным

    Archive & Archive::Write(const ISerializable & ob)
    {
        if (!read_) {
            Write(ob.GetClassId());
            ob.Write(*this);
        }
        else {
            throw(std::runtime_error("Stream is not open for writing"));
        }
        return *this;
    }


    Archive & Archive::Read(ISerializable & ob)
    {
        if (read_) {
            int id = -1;
            Read(id);
            std::auto_ptr < ISerializable > ptr( SerializableFactory::Instance().CreateObject(id) ); 
            if (0 != ptr.get() ) {
                ob = * ptr.release();
                ob.Read(*this);
            }
            else {
                throw(std::runtime_error("CreateObject() return 0"));
            }
        }
        else {
            throw(std::runtime_error("Stream is not open for reading"));
        }
        return *this;
    }

typedef  Ado::Recordset20Ptr Archive;

class User
{
public:
    _bstr_t name_;
    long age_;
    User(void);
    ~User(void);
    Archive & Read(Archive & ar);
    Archive & Write(Archive & ar) const;
};

Archive & User::Read(Archive & ar)
{
    _variant_t v = rs->Fields->Item[0L]->Value;
    name_ = VT_NULL != v.vt ? _bstr_t(v) : _bstr_t("oops!");
    v = rs->Fields->Item[1L]->Value;
    age_ = VT_NULL != v.vt ? (long)v : -1L;

    return ar;
}

Archive & User::Write(Archive & ar) const
{
    rs->AddNew();
    rs->Fields->Item[0L]->Value = name_;
    rs->Fields->Item[1L]->Value = age_;
    rs->Update();
}

    Archive rs_;
    rs_.CreateInstance(__uuidof(Ado::Recordset));
    rs_->CursorLocation = Ado::adUseClient;
    rs_->Fields->Append(_bstr_t(L"Имя"), Ado::adBSTR, 0, Ado::adFldUpdatable);  
    rs_->Fields->Append(_bstr_t(L"Возраст"), Ado::adUnsignedBigInt, 0, Ado::adFldUpdatable);
    rs_->Open(vtMissing, vtMissing, Ado::adOpenStatic, Ado::adLockOptimistic, Ado::adCmdUnspecified);

    struct _finddata_t fd = { 0 };
    long hFile = 0;
    if( -1L != (hFile = _findfirst(xmlFile, &fd)) )
        ::DeleteFile(xmlFile);

// от форыча 6-я студия ругается, но по всему тут нужен форыч
    for(std::vector< boost::shared_ptr<User> >::const_iterator it = users_.begin(); it != users_.end(); ++it) {
        (*it)->Write(rs_);
    }

    rs_->_xSave(xmlFile, Ado::adPersistXML);

    struct _finddata_t fd = { 0 };
    long hFile = 0;
    if( -1L == (hFile = _findfirst(xmlFile, &fd)) )    {
        throw std::runtime_error(_T("Враги стерли файл с юзверями!"));
    }

    rs_->Open(xmlFile, _bstr_t(L"Provider=MSPersist;"), Ado::adOpenForwardOnly, Ado::adLockReadOnly, Ado::adCmdFile);
    if (!rs_->adoEOF) {
        rs_->MoveFirst();
        while(!rs_->adoEOF) {
            boost::shared_ptr<User> user(new User());
            user->Read(rs_);
            users_.push_back(user);
        }
    }

А><tag_for_the_derived>
А>  <nasty_tag1>
А>     base1 members
А>  </nasty_tag1>
А>  <nasty_tag2>
А>     base2 members
А>  </nasty_tag2>
А>  derived members
А><tag_for_the_derived>
А>

derived::serialize(archive& arc)
{
//<Vadim>
  arc.begin("derived_tag");
//</Vadim>

  // либо так (в более примитивных подходах, требующих, чтобы функция сериализации была членом)
  // нам это не подходит, далее речь только о втором случае
  base::serialize(arc);       
 
  // либо так (в более продвинутых, вот это и хотим повторить) 
  arc.put(static_cast<base&>(*this));  // либо аналог: arc << static_cast<base&>(*this);

//<Vadim>
  //Сохранение мемберов derived
  ...
  arc.end("derived_tag");//Вообще-то эта строчка излишняя...
//</Vadim>

}

derived::serialize(archive& arc)
{
//<Vadim>
  archive::beginClass cl(arc."derived_tag");
//</Vadim>

  // либо так (в более примитивных подходах, требующих, чтобы функция сериализации была членом)
  // нам это не подходит, далее речь только о втором случае
  base::serialize(arc);       
 
  // либо так (в более продвинутых, вот это и хотим повторить) 
  arc.put(static_cast<base&>(*this));  // либо аналог: arc << static_cast<base&>(*this);

//<Vadim>
  //Сохранение мемберов derived
  ...
//</Vadim>
}

    Основная цель написания парсера была перевести работу с данными
    получеными их XML из Runtime в фазу компиляции. Т.е. достаточно
    много есть всяких решений которые делают вот так

    XML["FOO"]["BAR"]["BAZ"]=5;
    или
    XML.setParam("foo",6).setParam("bar",7);

    Но данные решения обнаруживают ощибки в Runtime т.е.
    если такого параметра в XML нет то обнаружено это не будет.

    Цель моего решения было заставить компилятор проверять
    параметры на правильность в Compile Time.

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

    Т.е. идеальный вариант это описание структуры

    class
    {
      int b;
      class {
        int a;
        string s;
      } subNode;
    } XML;

    Которая потом автосериализуется в XML и обратно, тогда
    обращения к ней делаются как

    XML.subNode.a=10;
    XML.subNode.s="foo";
    XML.b.55;

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

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

    Мне вообщем-то удалось эту проблему решить.
    описание структуры выглядит следующим образом

class Test: public XMLNode
{
public:
        Test() { fixup(); }
public:

        XML_VALUE(int,integer);
        XML_VALUE(QString,string);

        XML_NODE_BEGIN(Foobar)
                XML_VALUE(int,integer);
                XML_VALUE(QString,string);

                        XML_NODE_BEGIN(BarBazBarf)
                                XML_VALUE(int,integer);
                                XML_VALUE(int,another_integer);
                                XML_VALUE(QString,string);
                        XML_NODE_END(BarBazBarf);

                        XML_NODES_BEGIN(BarBazBarfMany)
                                XML_VALUE(int,integer);
                                XML_VALUE(int,another_integer);
                                XML_VALUE(QString,string);

                                XML_NODE_BEGIN(Foobar)
                                        XML_VALUE(int,integer);
                                        XML_VALUE(QString,string);
                                XML_NODE_END(Foobar);
                        XML_NODES_END(BarBazBarfMany);

        XML_NODE_END(Foobar);
};

В XML ей соответсвует следующая структура

<Test string="Test" integer="10" >
 <Foobar string="Test" integer="10" >
  <BarBazBarfMany another_integer="0" string="test string 1" integer="0" >
   <Foobar string="test string 2" integer="0" />
  </BarBazBarfMany>
  <BarBazBarfMany another_integer="0" string="test string 3" integer="0" >
   <Foobar string="test string 4" integer="0" />
  </BarBazBarfMany>
  <BarBazBarf another_integer="2009145416" string="Oanoiaua aaiiua" integer="1245104" />
 </Foobar>
</Test>

Обращение идет как положено

test.string="Test";
test.Foobar.string="Test2"

и тп.

Cейчас кратко опишу 2 основных жестких хака которые сделали это возможным.

Хак #1. Определение содержимого класса.

Класс Test должен как то получить в Runtime список всех своих
member-ов и указатели на них.

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

Дак вот где то в программе есть статическая переменная "стек"
Базовый класс запоминает сколько элементов лежит в стеке,
потом каждый Member в своем конструкторе кладет указатель
"this" на этот стек. После чего конструкторо самого класса
вызывает спец процедуру "fixup" и выгребает из стека все
указатели на своих member-ов.

Хак #2. Получение собственного имени в Runtime.
Задача, переменная в программе называется "B",
в момент компиляции это имя теряется, но нужно его получить
в Runtime чтобы знать с каким именем себя сериализовать.
Сделать это параметром шаблона нельзя

XMLValue<int, "name"> name;

т.к. параметры типа const char* не разрешены в шаблонах,
только int.

Решается это легко т.к. шаблоны разрешено
параметризовать классами

class xml_hack_name 
{
   QString name() { return "name" }
};
XMLValue<int, xml_hack_name> name;

Для того чтобы все 2 раза не писать я еще сделал макрос

#define XML_VALUE(type,name) \
        class xml_hack_##name 
        {
              QString name() { return #name }
        }; \
        XMLValue<type,xml_hack_##name> name;

И теперь все записывается вот так
        XML_VALUE(int,integer);

[boost] Re:What is the status of the Boost Serialization Library?

I am the author of the serialization library reviewed by boost last november.
This library is available in the files section under the name serialization6.zip(I think)
Though it fullfilled all the goals I originally set for such a library it
was not accepted into boost for a number of reasons.

Since then I have continued work to address the reasons for its
rejection. A few interested parties have also offered to help. Things
have proceeded as follows

a) better factoring of the implementation (done)
b) addition of all desired facitlities(done)

i) usage of compile time virtual functionality (CRTP)
ii) XML archives
iii) factoring out of type information and registration
iv) automatic selection of object tracking functionality
v) registration system for external names
vi) single entry point serialization (like jens maurer persistence.zip)
vii) miscelaneous other improvements.

c) final improvements in new implementation ( almost done)
d) decompostion of tests into tests of finer granularity(pending)
e) new tests for new features(pending)
f) rework of documentation to account for new features (pending)
g) check out on multiple compilers.(pending)

I would hope that I can get this done in the next 60-90 days. Fortunately
I amd currently unemployed.

I do not know if anyone else is currently working on anything like this.

There are several options if you're in a hurry. Each has a different
set of features and different interface. The documentation in serialization6.zip
lists the other packages that I happened to know about. The documentation
is a year old and at least one package (Eternity) has evolved since I mentioned
it in the documentation. I know for a fact that some users have been using
serialization6.zip library with satisfactory results. Unfortunately, the archives
created wth this version most likely won't be readable with the next version
I submit. This may be a factor.

Robert Ramey

>Yao Zhen wrote:
>I am very intrested in the Boost Serialization Library, and have read in
>gmane.comp.lib.boost.announce that this library has been reviewed.

>I am wondering what is the review result and current status of the library.