Hi Nicola, Nicola Santi wrote:
> >4. I don't understand how serialization of base classes should be done. > > In derive class serialization method remember to call the serialization > method of base class. > > void Derived::serialize( bin_archive &stream) { > // first base class serialization > Abase::serialize(stream); Ok, I see now. > > 5. .. Then, if you use put_object for storing ? if you store a > several different pointers to the same class, you'll have type name > stored many times, and it's likely it will be longer that the class data! > > put_object() stores the class conventional name than call the method > serialze(). get_object() retrieves the conventional name, create the > object, call the method serialize. > > If you do not need dynamic creation (because you know it?s type or > because it is allocated on the stack, etc.) create the object and call > its serialize() method instead of get_object(). I'm afraid I don't like this approach. You have 3 ways to serialize an object: 1. Call operator << 2. Call put_oject 3. Call serialize on object directly. That's quite confusing. > 7. (thinking aloud) .. > > >- The space is important. A single class may be 4-ints big, and > writing class name will double the size of data. > >- The speed is important. In one case, the type of data is known > during writing, and just raw bytes are added to a buffer. Adding > "typeid" call and a search for conventional name (you do it with linear > search now, but map is not O(1) as well), will not be acceptable. > > Same as previous point, if you know the type don?t store it. Otherwise > if you need dynamic creation assistance the name of the class should > necessarily has been stored in the archive: in this situation could be > of some help register the class with short name only for the duration of > storing and retrieving. OK, short name will help with the space issue. But still, lookup up that short name will take time. > > I recalled that someone suggested to Robert to separate class > registration to a separate component (possibly replacable). That would > be very good here. I could create custom class which will return id for > a type at compile-time. What do you think? > > I think could be interesting, please let me know more details about the > API you are suggesting and we could try to implement it. If I only new what API I am suggesting ;-) The originally idea came from something else, and it started to resonate with my needs recently. I'll try to think about something concrete. > > 1. The documentation on the web page could be better. > - I don't see "overview" anywhere. I see such document in the > distribution, but if you don't have overview instantly accessible, some > folks will not even bother to download the library. > - The "examples" web page does not contain examples, but just > mentions the ones from distribution. Having examples on the web would > be much better. > > I agree: I?ve change eternity web site this morning to follow your > suggestions. That's good. > 6. I believe there's not enough tests for your library. > Again, your are right. Could you help me in writing more tests? I will > appreciate it? I think that Robert's library has quite a plenty of tests. You can look for ideas there. > DESIGN CONSIDERATION > > 2. (DP) Binary serialization and XML serialization are entirely separate. > > Storing a primitive type in xml archive required an additional field > (the tag label) then storing the same field in binary archive. Moreover > retrieve that field required one other parameter (the position) that is > not needed in binary persistence. BTW, I don't understand why tag is required on loading. I would suppose that XML is just like binary stream, only you have extra annotations for the benefit of humans and tools. > One year ago a developer from French write me if it could be possible to > have only one serialize() method to store both xml and binary way. I > wrote the modification to eternity (moving a lot of methods from > xml_archive to archive ) and having serialization method like this: [..] > When this method is called for binary persistence it passes a lot of > parameters that are not using and loose the random access facility over > XML archive. Do you really things it is a good idea? With two methods > (serialize and xml_serialize) the class has more control over the > persistence engine and could choice to implement only one of the two ways. First, I don't yet get the idea of "random access facility". Thinking about uneeded data, I though that if you had template method: template<class Saver> void save(Saver& s) const { s << class_name("foo") << field_name("x") << x; } then a saver for binary data would have empty inline overloads for class_name and field_name manipulators. The compiler will surely optimize away all names manipulation and you won't pay for it. A saver for XML would make use of names, of course. > Ok, excuse me for this long reply (and my english). I have really > appreciate your notes and I will be very happy if could help me again, > as you wish. Let me know? You know, Nicola, I will be willing to help anybody who can present really good serialization library. But since there's Robert's code already, I don't know whom to help ;-) Both libraries appear to be similar, so it would be nice if you cooperate somehow. - Volodya _______________________________________________ Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost