Re:[boost] Re:Re:Re:Formal review: serialization

From: Robert Ramey (ramey_at_[hidden])
Date: 2004-04-26 12:02:55

Vladimir Prus wrote:

>Hmm... gotta look into this. What about my second question:

>>> 2. For random access I need to make sure that all saved objects have 
>>> export key. How do I do that? Not necessary out-of-the box but where 
>>> I can plug the check?

Actually, its not necessary that ALL saved objects have export keys.  Only
those objects that are serialized through polymorphic pointers need to be
exported or registered.  An attempt to serialize a polymorphic pointer that
has neither been exported nor explicitly registered will trigger a run-time
exception "unregistered_class".

If you wanted to enforce the idea that all types should be exported I
believe it would be possible to something like the following in your archive
class:

a) override implementation of save(class_id_type & t) and
save(class_id_optional_type) so that they set a flag.

b) override implementation of save(class_name & t) it sets a flag

c) override end_preamble so that it checks for an undesired set of flags.

I never considered this before so you'll have to check the above yourself.

>>> one for dynamic arrays with  element-wise save
>> 
>> I would envision one using
>> 
>> ar << element_count
>> For(i = 0; I < element_count; i++)
>> ar << element[i]
>> 
>> I'm not sure that its worth adding and documenting such an obvious and
>> trivial thing as a separate wrapper.

>But on loading you need to add 'new[]' call. So load and save become
>non-symmetric, and you need to split serialize, which is rather
>inconvenient.

Actually, I forget the original question.  But in any case, I'm wondering
about trying to anticipate every application.  OTOH, having considered again
dynamic_array I'm now more inclined to include it.  I'll take a look a the
other ones.  These would be described in the document under "serialization
wrappers".

> > There are cases when an object id is
> > assigned but not written to the archive I don't see these as having much
> > utility outside of serialization.

> So, it's not easily possible to plug a different algorithm?

In a general sense - NO.

Any of the "bookkeeping" types in common_?archive can be overloaded to
taste. Overloading these in a special way was how XML was implemented.  I'm
sure that these could be used for creating other special purpose archives
but I really can't know for any particular case until one tries to implement
them.

>>> Ah, I've missed that. Do I need to provide both 'type' and 'value'? 
>>> Can't serialization library work with just one?
> 
>> Could be.  I just provided both so that I could interoperate with mpl
>> without having to think about each specific case.

> But for user this can be inconvenient.

Actually I was thinking most users would use the macros.  If one fails to
include one that's used it should fail compilation so I don't see it's a
show stopper.  Actually I think it's easier just to always include both
rather than trying to document/remember which ones use which.

> It it possible that you make BOOST_EXPORT always
> register classes with the polymoprhic archive.
> and use polymoprhic archive as fallback for serializing classes?

I'm still fine tuning this (smart_cast anyone?).  But basically things work
like this.

a) Just as now, one could pre-compile a serialization instantiating code for
particular archives.  In this case one of the archives would be the
"polymorphic_?archive" class which is nothing but a bunch of virtual
function declarations.

b) when the application is built, a specific archive implemenatation is
selected. E.G polymorphic_text_?archive.  The is archive inherits the
implementation from text_?archive and the interface from
polymorphic_?archive.

c) the application will link with the pre-compiled classes.

I'm not sure this answers your question - but there it is.   

Thank god no ones asked about DLL implementations yet.

Robert Ramey