[boost] Re: an xml-binary persistence library

From: Robert Ramey (ramey_at_[hidden])
Date: 2003-04-19 12:58:14

 >> b) Certain usage features
 >> 	ii) inconvenient type registration requirement
 >> 	iii) requirement to pre-register classes to be saved as pointers
 >> 	through a base class
 >> 	iv) requirement to have separt save/load code for serialization 
functions
 >> b) your package has the same set of usage features (b above) that
 >> mine did and these were strenuously objected to.

>eternity, my library, use the same method for save/load  and do not 
>impose to using any base class. Could you help me understand this point, 
>expecially for b ii and iii ?

ii) I mis-understood something so I withdraw this observation

iii) 
        class A // abstract base class
        class B : public A	// derived class
        class C : public A	// derived class
        ...
        class D 
                A * a1 = new b();
                A * a2 = new c();
                A * a3 = new ? // unknown - could be b or c or ?
        ....
        D::serialize(stream & s)
                if(s.isloading)
                        s.get_object("B",  &a1);  // will this call serialization for B? or A:
                        // I would gess the above is equivalent to:
                        create("C", &a2);
                        s >> *a2;		// same question
                        create("?", &a3);	// what goes here?
                        s >> *a3;
                else
                        s.put_object("B", &a1); ?
                        etc.

I don't know if the above is clear but its the best I can do in a short message.  The
question really is "How are polymorphic pointers handled?"

iv)  This concern is that
        serialize(...
                if(isloading..
                        read a
                        read b
                        ...
                else
                        write a
                        write b
                        ...

is considered redundant, inconvenient and prone to hard to find dumb errrors.  Preference
was expressed for something like what was found in Jens's library

        serieralize(input or output stream)
                serialize(a)
                serialize(b)
                ....

So that input and output could never get out of sync

>Thank you very much for your suggestions and honest words: if I could be 
>of some help with your library, please let me know.

It is not my intention to discourage you. I think you've done a nice
job on your package.  I just wanted to be sure you know what's involved in
getting a library that many people have interest in accepted into boost.

I would suggest you review the information regarding serialization
and persistence in the boost developer's mailing list.  The search
function in the boost main page works great for this.  I think
this will give a more detailed idea about what boosters expect
(demand) for such a package.

Also in the files section, you will find my submission as well
as Jens Maurer's previous one.  I had originally looked as Jens's
as well as yours.  I had my experience with MFC which I found
useful but lacking in some areas.  Jens's package seemed much
different and I didn't really understand some aspects of it - much
to my later regret.

>N.

Robert Ramey