Blame view

3rdparty/boost_1_81_0/libs/serialization/doc/overview.html 6.76 KB
73ef4ff3   Hu Chunming   提交三方库
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
73
74
75
76
77
78
79
80
81
82
83
84
85
86
87
88
89
90
91
92
93
94
95
96
97
98
99
100
101
102
103
104
105
106
107
108
109
110
111
112
113
114
115
116
117
118
119
120
121
122
123
124
125
126
127
128
129
130
131
132
133
134
135
136
137
138
139
140
141
142
143
144
145
146
  <!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>Serialization - Overview</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="../../../index.htm"><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">Overview</h2>
      </td>
    </tr>
  </table>
  <hr>
  <dl class="index">
    <dt><a href="#Requirements">Requirements</a></dt>
    <dt><a href="#otherimplementations">Other Implementations</a></dt>
  </dl>
  <p>Here, we use the term <strong>"serialization"</strong> to mean
  the reversible deconstruction of an arbitrary set of C++ data structures
  to a sequence of bytes.  Such a system can be used to reconstitute
  an equivalent structure in another program context.  Depending on
  the context, this might used implement object persistence, remote
  parameter passing or other facility. In this system we use the term
  <strong>"archive"</strong> to refer to a specific rendering of this
  stream of bytes.  This could be a file of binary data, text data, 
  XML, or some other created by the user of this library.
  <h2><a name="Requirements"></a>Our goals for such a system are:</h2>
     <ol>
        <li>Code portability - depend only on ANSI C++ facilities.
  
        <li>Code economy - exploit features of C++ such as RTTI,
        templates, and multiple inheritance, etc. where appropriate to
        make code shorter and simpler to use.
  
        <li>Independent versioning for each class definition. That
        is, when a class definition changed, older files can still be
        imported to the new version of the class.
  
        <li>Deep pointer save and restore. That is, save and restore
        of pointers saves and restores the data pointed to.
  
        <li>Proper restoration of pointers to shared data.
  
        <li>Serialization of STL containers and other commonly used
        templates.
  
        <li>Data Portability - Streams of bytes created on one platform
        should be readable on any other.
  
        <li>Orthogonal specification of class serialization and archive format.
        That is, any file format should be able to store serialization
        of any arbitrary set of C++ data structures without having to
        alter the serialization of any class.
  
        <li>Non-intrusive. Permit serialization to be applied to
        unaltered classes. That is, don't require that classes to be
        serialized be derived from a specific base class or implement
        specified member functions. This is necessary to easily
        permit serialization to be applied to classes from class
        libraries that we cannot or don't want to have to alter.
  
        <li> The <strong>archive</strong> interface must be simple
        enough to easily permit creation of a new type of archive.
  
        <li> The <strong>archive</strong> interface must be rich
        enough to permit the creation of an <strong>archive</strong>
        that presents serialized data as XML in a useful manner.
     </ol>
  
  <h2><a name="otherimplementations"></a>Other implementations</h2>
      Before getting started I searched around for current
      implementations. I found several. 
  
      <ul>
        <li><u>MFC</u> This is the one that I am very familiar with.
        I have used it for several years and have found it very useful.
        However it fails requirements 1, 2, 3, 6, 7, and 9. In spite
        of all the requirements not fulfilled, this is the most
        useful implementation I've found. It turns out that class
        versioning - partially implemented in MFC - really is
        indispensable for my applications. Inevitably, version 1.x of
        a shipping program needs to store more information in files
        than was originally provided for. MFC is the only one of these
        implementations that supports this - though only for the most
        derived class. Still it's better than nothing and does the
        job. MFC doesn't implement serialization of STL collections.
        Though it does so for MFC collections.
  
        <li><u>CommonC++ libraries</u> <a href="bibliography.html#1">[1]</a>
        As far as I can tell, this
        closely follows the MFC implementation but does address a few
        of the issues. It is portable and creates portable archives but
        skips versioning. It does support proper and complete
        restoration of pointers and STL collections. It does address
        compression though not in the way that I would prefer. The
        package would also benefit from having better documentation.
        So it fails to address 2, 3, 7, 8, and 9.
  
        <li><u>Eternity</u> <a href="bibliography.html#2">[2]</a> 
        This is a bare bones package. It
        seems well coded but it really needs documentation and
        examples. It's not obvious how to use it without time
        consuming study of the source code. Recent versions do support
        files in XML format.  This Fails 3, 6, 7?, 8, and 9. 
  
        <li><u>Holub's implementation</u> <a href="bibliography.html#3">[3]</a> This is the article that
        first got me thinking about my own requirements for
        a serialization implementation. Interesting and worth
        the read if you can overlook the arrogant tone of the prose.
        This implementation fails 2, 3, 4, 5, and 6.
  
        <li><u>s11n</u> <a href="bibliography.html#13">[13]</a>
        This library has similar goals to this one. Some aspects of the
        implemenation are also similar.  As of this writing, it would seem that:
        <ul>
            <li>Portability(1) is guarenteed only for recent versions of GCC.
            <li>Versioning(3) of class definitions is not explicitly supported by
            the library.
            <li>it doesn't seem to automatically account for shared pointers(5).
            I concluded this from the documentation as well as the statement that
            serialization of graph like structures is not supported.
        </ul>
        Its has lots of differences - and lots in common with this implementation. 
      </ul>
  <hr>
  <p>Revised 1 November, 2004 
  <p><i>&copy; 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>