Boost logo

Boost :

From: rameysb (ramey_at_[hidden])
Date: 2002-02-27 16:48:51

--- In boost_at_y..., "Yitzhak Sapir" <ysapir_at_y...> wrote:
> > 3) ar << * static_cast<const bus_stop *>(this);
> >
> Implementing serialization with << and >> is nice, and it allows
you to
> write code like this:
> socketstream << some_object;
> cout << some_object;
> which looks very generic. In fact, you may not even need to know
> type of stream you're serializing too. However, This is also
> problematic. << and >> were not meant for serialization of
> non-fielded data as far as I can see. That is, cout << 23 << 34;
> print 2334. Sent to a file and read back to an int, you'd
read "2334".
> There are two possibilities I know of:
> 1) Require your users to be aware of this: All users do cout << 23
<< '
> ' << 34 << ' '; after every int serialized. This is problematic as
> requires your users to be aware that they have to print fields
> the data. Besides, for serializing non formatted data, it is quite
> space-consuming. (A 4 byte number can take 10 ascii digits, or 20
> unicode chars).
> 2) Reimplement num_get and num_put and place them in the locale of
> serialized stream. This is problematic as num_get and num_put do
> have complementary functions. Particularly, num_put can only
> types bool, long, and unsigned long as far as integers are
> num_get can read shorts, etc. Consider now that a user writes a
> to the stream, then the long put function will be written, and a
> will be consequently read. So num_get's short methods would have
to be
> reimplemented to also know that they read a long.
> Both of these are compounded by the fact that formatted
> takes place with << and >>, which is much slower (as it must
implement a
> more robust system) than would need to be for the purpose of
> non-formatted serialization.
> This only happens if you use a basic_*stream derivative, but it
> (from a brief look at the code) that you are. I should also note
> you may want to make the archive templated by Char and CharTraits,
> follow the basic_*archive/*archive/w*archive framework. So this
way if
> you're serializing to a wchar_t stream that has a unicode code
> conversion you don't have to lose information on serializing a
> or have to follow additional steps to prevent this.

input and output archives are not derived from streams. They are
implement in terms of strings. This is addressed in the "Rational"
section of the documentation. The reference to the stream to be used
is passed when the archive is created. So all issues associated with
streams are orthogonal to archives.

also the rational for using text for numbers - is portability from
machine to machine. binary portability would be a huge hassle and
never be complete. Its bad enough that there are little and big
endien machines, floating point formats vary from machine to
machine. I believe that the only practical way to make archives
portable across machines to use text files.

Robert Ramey

Boost list run by bdawes at, gregod at, cpdaniel at, john at