[boost] Re: Serialization Library Review

From: Robert Ramey (ramey_at_[hidden])
Date: 2002-11-14 01:39:27

Alberto Barbati wrote

>>>2) A most needed addition to the design is to provide a sort of  
>> "registry" object..... 
>>  
>> This has been a hot topic.  It is really not possible to achieve the 
>> desired results.  I will add a section to th rationale explaining this 
>> in detail,  

>Please note that the "registry" class I described *does not* attempt to 
>solve the broader issue of UUIDs I read about in the discussion between 
>you and Vladimir. My proposal is just a way to separate the 
>"registration" part from the "serialization" into two different 
>compontents. Still the classes will be matched according to their 
>registration order, as it happens now. I am ready to discuss the 
>opportunity and/or usefulness of this approach, but I don't see the 
>reason why this could not be done.

I considered this approach and found the following problem

Suppose I automatically add the class info to a global collection of
"registered types". This I can easily do.  Now when I create an
archive I can

a) register all the types in the global collection in the archive.
bad idea - this would require that the reading program register
all the types of the writing program.  An intolerable requirement
b) register types as needed as the library is written
wouldn't work - on loading, we wouldn't know which types to register
c) after creating the archive, append a "registration file"  on loading,
process the "registration file first. In my view this cure is worse
than the disease.

>>One note: the library, as it is, *does not* support Unicode output, as  
>>stated. The library supports wide streams, yes, but that does not mean  
>>Unicode support. 
> So what do I have to do exactly in the warchive specialization to generat 
> Unicode output? 

>As I said in my post, you have to imbue the stream with a locale holding 
>the correct codecvt facet, before using it to serialize. Unfortunately, 
>such a facet is not part of the ANSI standard and is the subject of a 
>separate proposal of mine (see thread "codecvt facets for 
>utf8/utf16/utf32").

>BTW, with the current implementation even doing so is completely 
>useless, as there are lines like this:

     os.imbue(std::locale::classic());

>that reset the locale of the streams to the "dumb" default. Such lines 
>are IMO both unnecessary and conceptually wrong, and should be removed.

I'm still at a loss.  Aside from addressing the "classic" above, what exactly
do you recommend I do?  How about if I change the wording to specify
that the library supports wide streams and leave unicode out of it?

>On a different topic, I found a portability issue. The current 
>implementation record in the archives the size of the basic types int, 
>long, float and double. This gives you a *false* sense of security that 
>the "writing" and "reading" platform agree on the type size.

this is for the native binary archive which is explicitly described as
being non-portable.  It was included because some users felt it
would be more efficient.  It has no pretensions at all to portability.
Knowing that some one will ignore this admonishment and
try to move such a binary to another machine architecture, 
Included free detection so that it would crash in a more 
graceful manner.

Robert Ramey