Re: [Boost-users] Using boost::serialization inreal-timewithoutallocating memory

Peter Soetens wrote:

On Fri, Sep 18, 2009 at 23:56, Robert Ramey wrote:

...

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.

I would have to look into this in more detail to really provide an answer. Clearly, the fact that that "trivial_archive" inherits from common_archive would suggest you're correct about this or maybe that something else is out of whack. I'll look into it when I have nothing else to do. Given you've already wrapped your head around this whole issue - maybe you want to suggest how something might be changed. My first approach would be to figure out why save/load object is required to compile. Perhaps this is just an implementation artifact. Ideally the implementation could be slightly refactored to support the original concept.

...

...

...

? 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 ?

That would seem correct to me. There is nothing in the archive concept which suggests that all potential operate must be supported in some specific way. That is, it's not a bug if some archive doesn't implement some function like serializing pointers in some specific way. Of course it turns out that they have been implemented in the archives provided in the way that to me seemed most useful. And judging from way the library seems to be used - others argree with me. However, I don't/didn't want to close off other implementations such as yours. I've strived mightely to keep archive and serialization concepts orthogonal. I believe that I have been mostly successful.

...

...

...

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 sort of assumed that you wanted to avoid that. Truth is I didn't go into detail about your requirements, I just pointed you in the direction which I thought would do the most good. I am gratified that you've been able to accomplish something that I never forsaw while including just parts of the library which you needed. This makes me thing that I got it mostly right.

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.

I would love to include such an example (case study). However I have a few observations based on years of practicle experience in helping users with the library. * Focused - it should address one - and only one - specific problem * Simple - easy to follow * Short - not require a lot of time to follow through * Useful - should provide a really useful function rather than a "toy problem". This provides more motivation for users to look at it detail and will likely be the basis. * Should be templated where appropriate. See "Useful" above. But there's a larger point. Presenting it as a template fits in with the other boost libraries. Also - template parameters tend to show the separation of the "algorithm" from the "arguments" (template parameters) which actually helps make things more clear. Just one man's opinion. * When the example is added to the package - it is added to the test suite so that it can be tweaked for all the compilers run in the test trunk. * Documentation - a nice page describing the motiviation for the example etc. If an example doesn't do the above, it creates a lot more user queries than it solves. It is my intention that any addition to the library result in: * no loss in functionality * no increase in requirements for user support * no new bugs * improvement in at least one of the above. That is, any addition to the library and/or it's documentation should result in a strict improvement. I realise that it makes it look that adding a simple example is a lot more work than it first appears. That is in fact the case. Having said all that - I still would like to see something like this included. Other examples demo_fast_archive and demo_portable_binary have result in full blown archives of thier own.

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'.

I havn't look into it enough to really understand this. It goes to show that a simple idea can't help evolving to something non-trivial as one examines it more closely. Robert Ramey