| Brian Silverman | 8867871 | 2018-08-04 23:56:48 -0700 | [diff] [blame^] | 1 | <!doctype HTML PUBLIC "-//W3C//DTD HTML 4.01 Transitional//EN" "http://www.w3.org/TR/html4/loose.dtd"> |
| 2 | <html> |
| 3 | <!-- |
| 4 | (C) Copyright 2002-4 Robert Ramey - http://www.rrsd.com . |
| 5 | Use, modification and distribution is subject to the Boost Software |
| 6 | License, Version 1.0. (See accompanying file LICENSE_1_0.txt or copy at |
| 7 | http://www.boost.org/LICENSE_1_0.txt) |
| 8 | --> |
| 9 | <head> |
| 10 | <meta http-equiv="Content-Type" content="text/html; charset=UTF-8"> |
| 11 | <link rel="stylesheet" type="text/css" href="../../../boost.css"> |
| 12 | <link rel="stylesheet" type="text/css" href="style.css"> |
| 13 | <title>Seriealization - Rationale</title> |
| 14 | </head> |
| 15 | <body link="#0000ff" vlink="#800080"> |
| 16 | <table border="0" cellpadding="7" cellspacing="0" width="100%" summary= |
| 17 | "header"> |
| 18 | <tr> |
| 19 | <td valign="top" width="300"> |
| 20 | <h3><a href="http://www.boost.org"><img height="86" width="277" alt="C++ Boost" src="../../../boost.png" border="0"></a></h3> |
| 21 | </td> |
| 22 | <td valign="top"> |
| 23 | <h1 align="center">Serialization</h1> |
| 24 | <h2 align="center">Rationale</h2> |
| 25 | </td> |
| 26 | </tr> |
| 27 | </table> |
| 28 | <hr> |
| 29 | <dl class="index"> |
| 30 | <dt><a href="#serialization">The term "serialization" is preferred to "persistence"</a></dt> |
| 31 | <dt><a href="#archives">Archives are not streams</a></dt> |
| 32 | <dt><a href="#strings">Strings are treated specially in text archives</a></dt> |
| 33 | <dt><a href="#typeid"><code style="white-space: normal">typeid</code> information is not included in archives</a></dt> |
| 34 | <!-- |
| 35 | <dt><a href="#footnotes">Footnotes</a></dt> |
| 36 | --> |
| 37 | </dl> |
| 38 | <h2><a name="serialization"></a>The term "serialization" is preferred to "persistence"</h2> |
| 39 | <p> |
| 40 | I found that persistence is often used to refer |
| 41 | to something quite different. Examples are storage of class |
| 42 | instances (objects) in database schema <a href="bibliography.html#4">[4]</a> |
| 43 | This library will be useful in other contexts besides implementing persistence. The |
| 44 | most obvious case is that of marshalling data for transmission to another system. |
| 45 | <h2><a name="archives"></a>Archives are not streams</h2> |
| 46 | <p> |
| 47 | Archive classes are <strong>NOT</strong> derived from |
| 48 | streams even though they have similar syntax rules. |
| 49 | <ul> |
| 50 | <li>Archive classes are not kinds of streams though they |
| 51 | are implemented in terms of streams. This |
| 52 | distinction is addressed in <a href="bibliography.html#5">[5]</a> item number 41. |
| 53 | <li>We don't want users to insert/extract data |
| 54 | directly into/from the stream . This could |
| 55 | create a corrupted archive. Were archives |
| 56 | derived from streams, it would possible to |
| 57 | accidentally do this. So archive classes |
| 58 | only define operations which are safe and necessary. |
| 59 | <li>The usage of streams to implement the archive classes that |
| 60 | are included in the library is merely convenient - not necessary. |
| 61 | Library users may well want to define their own archive format |
| 62 | which doesn't use streams at all. |
| 63 | </ul> |
| 64 | <h2><a name="primitives"></a>Archive Members are Templates |
| 65 | Rather than Virtual Functions</h2> |
| 66 | The previous version of this library defined virtual functions for all |
| 67 | primitive types. These were overridden by each archive class. There were |
| 68 | two issues related to this: |
| 69 | </ul> |
| 70 | <li>Some disliked virtual functions because of the added execution time |
| 71 | overhead. |
| 72 | <li>This caused implementation difficulties since the set of primitive |
| 73 | data types varies between platforms. Attempting to define the correct |
| 74 | set of virtual functions, (think <code style="white-space: normal">long long</code>, |
| 75 | <code style="white-space: normal">__int64</code>, |
| 76 | etc.) resulted in messy and fragile code. Replacing this with templates |
| 77 | and letting the compiler generate the code for the primitive types actually |
| 78 | used, resolved this problem. Of course, the ripple effects of this design |
| 79 | change were significant, but in the end led to smaller, faster, more |
| 80 | maintainable code. |
| 81 | </ul> |
| 82 | <h2><a name="strings"></a><code style="white-space: normal">std::strings</code> are treated specially in text files</h2> |
| 83 | <p> |
| 84 | Treating strings as STL vectors would result in minimal code size. This was |
| 85 | not done because: |
| 86 | <ul> |
| 87 | <li>In text archives it is convenient to be able to view strings. Our text |
| 88 | implementation stores single characters as integers. Storing strings |
| 89 | as a vector of characters would waste space and render the archives |
| 90 | inconvenient for debugging. |
| 91 | <li>Stream implementations have special functions for <code style="white-space: normal">std::string</code> |
| 92 | and <code style="white-space: normal">std::wstring</code>. |
| 93 | Presumably they optimize appropriately. |
| 94 | <li>Other specializations of <code style="white-space: normal">std::basic_string</code> are in fact handled |
| 95 | as vectors of the element type. |
| 96 | </ul> |
| 97 | </p> |
| 98 | <h2><a name="typeid"></a><code style="white-space: normal">typeid</code> information is not included in archives</h2> |
| 99 | <p> |
| 100 | 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> |
| 101 | in the archive. This created difficulties as <code style="white-space: normal">std::type_of::name()</code> is not portable and |
| 102 | not guaranteed to return the class name. This makes it almost useless for implementing |
| 103 | archive portability. This topic is explained in much more detail in |
| 104 | <a href="bibliography.html#6">[7] page 206</a>. It turned out that it was not necessary. |
| 105 | As long as objects are loaded in the exact sequence as they were saved, the type |
| 106 | is available when loading. The only exception to this is the case of polymorphic |
| 107 | pointers never before loaded/saved. This is addressed with the <code style="white-space: normal">register_type()</code> |
| 108 | and/or <code style="white-space: normal">export</code> facilities described in the reference. |
| 109 | In effect, <code style="white-space: normal">export</code> generates a portable equivalent to |
| 110 | <code style="white-space: normal">typeid</code> information. |
| 111 | |
| 112 | <!-- |
| 113 | <h2><a name="footnotes"></a>Footnotes</h2> |
| 114 | <dl> |
| 115 | <dt><a name="footnote1" class="footnote">(1)</a> {{text}}</dt> |
| 116 | <dt><a name="footnote2" class="footnote">(2)</a> {{text}}</dt> |
| 117 | </dl> |
| 118 | --> |
| 119 | <hr> |
| 120 | <p><i>© Copyright <a href="http://www.rrsd.com">Robert Ramey</a> 2002-2004. |
| 121 | Distributed under the Boost Software License, Version 1.0. (See |
| 122 | accompanying file LICENSE_1_0.txt or copy at http://www.boost.org/LICENSE_1_0.txt) |
| 123 | </i></p> |
| 124 | </body> |
| 125 | </html> |