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

Subject: Re: [Boost-users] Using boost::serialization in real-timewithoutallocating memory
From: Peter Soetens (peter.soetens_at_[hidden])
Date: 2009-09-21 06:10:49

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.

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