123456789101112131415161718192021222324252627282930313233343536373839404142434445464748495051525354555657585960616263646566676869707172737475767778798081828384858687888990919293949596979899100101102103104105106107108109110111112113114115116117118119120121122123124125 |
- <!doctype HTML PUBLIC "-//W3C//DTD HTML 4.01 Transitional//EN" "http://www.w3.org/TR/html4/loose.dtd">
- <html>
- <!--
- (C) Copyright 2002-4 Robert Ramey - http://www.rrsd.com .
- Use, modification and distribution is subject to the Boost Software
- License, Version 1.0. (See accompanying file LICENSE_1_0.txt or copy at
- http://www.boost.org/LICENSE_1_0.txt)
- -->
- <head>
- <meta http-equiv="Content-Type" content="text/html; charset=UTF-8">
- <link rel="stylesheet" type="text/css" href="../../../boost.css">
- <link rel="stylesheet" type="text/css" href="style.css">
- <title>Seriealization - Rationale</title>
- </head>
- <body link="#0000ff" vlink="#800080">
- <table border="0" cellpadding="7" cellspacing="0" width="100%" summary=
- "header">
- <tr>
- <td valign="top" width="300">
- <h3><a href="http://www.boost.org"><img height="86" width="277" alt="C++ Boost" src="../../../boost.png" border="0"></a></h3>
- </td>
- <td valign="top">
- <h1 align="center">Serialization</h1>
- <h2 align="center">Rationale</h2>
- </td>
- </tr>
- </table>
- <hr>
- <dl class="index">
- <dt><a href="#serialization">The term "serialization" is preferred to "persistence"</a></dt>
- <dt><a href="#archives">Archives are not streams</a></dt>
- <dt><a href="#strings">Strings are treated specially in text archives</a></dt>
- <dt><a href="#typeid"><code style="white-space: normal">typeid</code> information is not included in archives</a></dt>
- <!--
- <dt><a href="#footnotes">Footnotes</a></dt>
- -->
- </dl>
- <h2><a name="serialization"></a>The term "serialization" is preferred to "persistence"</h2>
- <p>
- I found that persistence is often used to refer
- to something quite different. Examples are storage of class
- instances (objects) in database schema <a href="bibliography.html#4">[4]</a>
- 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.
- <h2><a name="archives"></a>Archives are not streams</h2>
- <p>
- Archive classes are <strong>NOT</strong> derived from
- streams even though they have similar syntax rules.
- <ul>
- <li>Archive classes are not kinds of streams though they
- are implemented in terms of streams. This
- distinction is addressed in <a href="bibliography.html#5">[5]</a> item number 41.
- <li>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.
- <li>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.
- </ul>
- <h2><a name="primitives"></a>Archive Members are Templates
- Rather than Virtual Functions</h2>
- 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:
- </ul>
- <li>Some disliked virtual functions because of the added execution time
- overhead.
- <li>This caused implementation difficulties since the set of primitive
- data types varies between platforms. Attempting to define the correct
- set of virtual functions, (think <code style="white-space: normal">long long</code>,
- <code style="white-space: normal">__int64</code>,
- 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.
- </ul>
- <h2><a name="strings"></a><code style="white-space: normal">std::strings</code> are treated specially in text files</h2>
- <p>
- Treating strings as STL vectors would result in minimal code size. This was
- not done because:
- <ul>
- <li>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.
- <li>Stream implementations have special functions for <code style="white-space: normal">std::string</code>
- and <code style="white-space: normal">std::wstring</code>.
- Presumably they optimize appropriately.
- <li>Other specializations of <code style="white-space: normal">std::basic_string</code> are in fact handled
- as vectors of the element type.
- </ul>
- </p>
- <h2><a name="typeid"></a><code style="white-space: normal">typeid</code> information is not included in archives</h2>
- <p>
- I originally thought that I had to save the name of the class specified by <code style="white-space: normal">std::type_of::name()</code>
- in the archive. This created difficulties as <code style="white-space: normal">std::type_of::name()</code> 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
- <a href="bibliography.html#6">[7] page 206</a>. 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 <code style="white-space: normal">register_type()</code>
- and/or <code style="white-space: normal">export</code> facilities described in the reference.
- In effect, <code style="white-space: normal">export</code> generates a portable equivalent to
- <code style="white-space: normal">typeid</code> information.
- <!--
- <h2><a name="footnotes"></a>Footnotes</h2>
- <dl>
- <dt><a name="footnote1" class="footnote">(1)</a> {{text}}</dt>
- <dt><a name="footnote2" class="footnote">(2)</a> {{text}}</dt>
- </dl>
- -->
- <hr>
- <p><i>© Copyright <a href="http://www.rrsd.com">Robert Ramey</a> 2002-2004.
- Distributed under the Boost Software License, Version 1.0. (See
- accompanying file LICENSE_1_0.txt or copy at http://www.boost.org/LICENSE_1_0.txt)
- </i></p>
- </body>
- </html>
|