On Fri, Sep 18, 2009 at 23:56, Robert Ramey
Peter Soetens wrote:
That's it ! I used the wrong load/save functions. I cleaned up the archives and documented a bit. The only obscurity is that both classes required a 'save/load_object()' function, while this is not documented as such in the Archive Concept pages. Is this a recent addition (I'm using Boost 1.37.0 btw)
This would be due to the fact that even the "trivial_archive" inherits functionality from common_?archive. The archive concept doesn't require this - but most archives will want to do this - then override the implementation of common_?archive.
That's not my point. As I understand the 'Loading/Storing Archive Concept', any archive that implements the listed functions should be able to process 'ar << data;' if the serialization handler for data is defined. My archive implemented the concept fully, but did not compile because of a missing function. The only conclusion I can make is that the concept is not complete, or violated because people only tested it with the common base class and started to assume some functions were there while they are not required to be.
? What about save/load_pointer etc ?
truth is I don't remember all of this stuff. But it would seem that the serialization of pointers is a lower level. This makes sense since there is more than one idea about how to save/restore a pointer. The current implementation creates a new object when a pointer is de-serialized. But it didn't have to be this way. Someone else might want to define it as to just restore the value pointed to. Someone else might want to prohibit it. et.
I left most/all of these exotic functions empty. I wonder in which situations they will be called ? Should I put an assert(false) in them ?
If it were me, I would leave them undeclared.
Such that the user gets a compile time warning when he want's to use these features ?
I renamed the class to binary_object_archive.hpp
and I would have chose a different name that reflects the more specialized nature of this implementation. Also binary_object is used in the library to mean something specifice. Also the archives in the the library are templated on stream type binary/text - so binary isn't such a great name either. maybe something like
(binary | text) _static_(i/o)archive
static sort of suggests that there is no dynamic memory allocation.
I'm merely suggesting it to add to the examples directory, so templating on a stream type did not seem necessary (other examples take shortcuts as well). I would agree with many more shortcomings if this was to be added to the library itself. IMHO 'static' is an effect of the level 2-only + binary serialization of this archive. I wanted to stress in the name that 'class'/polymorphic types can not be serialized with this archive (I'd need to add the boost static assert, but I don't know if std::vector would still work then). I was suggesting before that we could make examples for each serialization level. Then we could also name them 'binary_level1_?archive', 'binary_level2_?archive', 'binary_level3_?archive'. YMMV. Peter