Serialization

Rationale

The term "serialization" is preferred to "persistence"
Archives are not streams
Strings are treated specially in text archives
typeid information is not included in archives

The term "serialization" is preferred to "persistence"

I found that persistence is often used to refer to something quite different. Examples are storage of class instances (objects) in database schema [4] This library will be useful in other contexts besides implementing persistence. The most obvious case is that of marshalling data for transmission to another system.

Archives are not streams

Archive classes are NOT derived from streams even though they have similar syntax rules.

Archive classes are not kinds of streams though they are implemented in terms of streams. This distinction is addressed in [5] item number 41.
We don't want users to insert/extract data directly into/from the stream . This could create a corrupted archive. Were archives derived from streams, it would possible to accidentally do this. So archive classes only define operations which are safe and necessary.
The usage of streams to implement the archive classes that are included in the library is merely convenient - not necessary. Library users may well want to define their own archive format which doesn't use streams at all.

Archive Members are Templates Rather than Virtual Functions

The previous version of this library defined virtual functions for all primitive types. These were overridden by each archive class. There were two issues related to this:

Some disliked virtual functions because of the added execution time overhead.

This caused implementation difficulties since the set of primitive data types varies between platforms. Attempting to define the correct set of virtual functions, (think long long, __int64, etc.) resulted in messy and fragile code. Replacing this with templates and letting the compiler generate the code for the primitive types actually used, resolved this problem. Of course, the ripple effects of this design change were significant, but in the end led to smaller, faster, more maintainable code.

`std::strings` are treated specially in text files

Treating strings as STL vectors would result in minimal code size. This was not done because:

In text archives it is convenient to be able to view strings. Our text implementation stores single characters as integers. Storing strings as a vector of characters would waste space and render the archives inconvenient for debugging.
Stream implementations have special functions for std::string and std::wstring. Presumably they optimize appropriately.
Other specializations of std::basic_string are in fact handled as vectors of the element type.

`typeid` information is not included in archives

I originally thought that I had to save the name of the class specified by std::type_of::name() in the archive. This created difficulties as std::type_of::name() is not portable and not guaranteed to return the class name. This makes it almost useless for implementing archive portability. This topic is explained in much more detail in [7] page 206. It turned out that it was not necessary. As long as objects are loaded in the exact sequence as they were saved, the type is available when loading. The only exception to this is the case of polymorphic pointers never before loaded/saved. This is addressed with the register_type() and/or export facilities described in the reference. In effect, export generates a portable equivalent to typeid information.