[boost] Re: Serialization Submission version 6

From: Robert Ramey (ramey_at_[hidden])
Date: 2002-11-17 00:15:07

>From: Alberto Barbati <abarbati_at_[hidden]>
>This solution does not address the objections in my last post in the 
>original thread. You seem really concerned about this. We could meet in 
>the middle with this solution, instead:

There are a couple of issues here

1) changing the state of the stream while serializing.  My implementation initialized the stream
and never contemplated that the same stream might be used for other things.  That is that
serialized data might be "embedded" as part of a larger stream.

Apparently this is an issue for some people. I don't see it as a large issue but
it as easy to address.  

Basically, I can capture the stream state when it is attached
to an archive and restore the stream state when the archive is closed.  My previous
example only considered the locale as the stream state.  After perusing BOOST
documentation I found the concept of "io state savers".  I realize that there are other
aspects of the stream state that might need saving as well.  As time permits I will
look into this

2) the function the stream in serialization

The archive implementation is a means to store serialized data.  Any number of
derivations from the base class are possible and even useful.  The archive
concept as represented by the base classes basic_[i|o]archive presumes
no particular method of data storage.  Its only requirement is that it be able to
store data in a sequence and recover data in the same sequence.

One method of storing/recovering the data is to use a sequence of characters
or wide characters.  That is a C++ stream.

This has some major benefits:

a) All the code required to convert any C++ datatype into characters or wide
characters exists and is part of the standard library and is guarenteed to work.

b) All the file handling is implemented as well

The fact that streams include lots of facilities such as local, punctuation, etc
is not relevent to our usage in text archives.  We only need to be concerned
about this to the extent that they might create portability problems. Hence
I set the locale for all streams used for serialization to "classic".  This is
the correct thing to do.  The purpose of serialization is to restore the C++
data types that we started with.  We don't want the data altered by
the stream processing.

Another way of saying this is that streams have lots of facilities for
dealing with human readable text in a country/language independent
way.  In this context the text is dealt with only by our serialization
system so these facilities should not be used.

>> Another observation:
>> 
>> I note that my test.cpp program includes wchar_t member variables initialized
>> to values in excess of 256.
>> The system doesn't seem to lose any informaton in storing/loading to a stream
>>  with classic locale.

I double checked.

I have functions in both char and wchar_t versions of text archives to handle both strings
of chars and wstrings.  This created a couple of problems.  The most obvious was what about
strings containing embedded blanks. - and other punctuation.  Single characters such a space
was also a problem. First I implemented them a sequence of short integers. That worked
fine but I was concerned that it wasted space, was slow, and inconvenient for debugging.
So I made special functions for i/o of string and wstring which just write a string length
and then stream out the string buffer as binary.

So I never have the problem that unicode or local o anything else interfers with my serialization.
This is a side effect of the fact that the usage of the stream was carefully limited to the purpose at hand.

Of course this raises the question why support wstreams at all? We're not using its advantages
(unless we have a lot of unicode text to store) and it doubles the required space.

In summary my view is that:

a) locale doesn't matter to us as long as we always use the same one
b) leave the stream in the state you found it.

Robert Ramey