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

Subject: Re: [Boost-users] Using boost::serialization inreal-timewithoutallocating memory
From: Robert Ramey (ramey_at_[hidden])
Date: 2009-09-21 13:10:15

Peter Soetens wrote:
> On Fri, Sep 18, 2009 at 23:56, Robert Ramey <ramey_at_[hidden]> 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