mirror of
https://github.com/boostorg/serialization.git
synced 2026-01-27 19:32:07 +00:00
@@ -44,10 +44,10 @@ http://www.boost.org/LICENSE_1_0.txt)
|
||||
<li>Tonko Juricic helped refine and complete project files for VC 7.1 ide
|
||||
<li><a href="http://www.boost.org/people/rene_rivera.htm">Rene Rivera</a> tracked down several issues related to
|
||||
Code Warrior, toolset configuration and bjam and much else.
|
||||
<li>Martin Ecker detected (and fixed!) a number of sublte errors regarding cyclic
|
||||
<li>Martin Ecker detected (and fixed!) a number of subtle errors regarding cyclic
|
||||
pointers, shared pointers. He also built the library as a DLL and raised some issues
|
||||
<li>Pavel Vozenilek invested much effort in review of code and documentation
|
||||
resulting in many improvements. In addition he help a lot with porting to other
|
||||
resulting in many improvements. In addition he helped a lot with porting to other
|
||||
platforms including VC 6.0, Intel, and especially Borland.
|
||||
<li><a href="http://www.boost.org/people/jens_maurer.htm">Jens Maurer</a> and
|
||||
<a href="http://www.boost.org/people/beman_dawes.html">Beman Dawes</a> who got the boost
|
||||
@@ -76,7 +76,7 @@ http://www.boost.org/LICENSE_1_0.txt)
|
||||
Mr. Rozenthal in particular wrote an incredibly insightful analysis
|
||||
that has driven all subsequent development that has resulted in the
|
||||
current package.
|
||||
<li>Dave Harris proposal and spirited defense of it lead to a re-thinking
|
||||
<li>Dave Harris proposal and spirited defense of it led to a re-thinking
|
||||
of the overrides for serialization of pointers. This resulted in a simpler
|
||||
and more effective method of accounting for non-default constructors
|
||||
required by serialization of pointers and STL collections.
|
||||
|
||||
@@ -35,7 +35,7 @@ http://www.boost.org/LICENSE_1_0.txt)
|
||||
|
||||
<h3><a name="trivial">Trivial Archive</a></h3>
|
||||
The <a href="archives.html"><strong>Archive</strong></a> concept specifies the functions that a
|
||||
class must implement to in order to be used to serialize
|
||||
class must implement in order to be used to serialize
|
||||
<a href="serialization.html"><strong>Serializable</strong></a> types.
|
||||
|
||||
Our discussion will focus on archives used for saving as the hierarchy is exactly analogous
|
||||
@@ -77,22 +77,22 @@ For an example see
|
||||
<a href="../example/demo_trivial_archive.cpp" target="demo_trivial_archive">
|
||||
<code style="white-space: normal">demo_trivial_archive.cpp</code></a>.
|
||||
Of course this program won't produce any output as it is. But it provides
|
||||
the starting point for a simple class which can be used to log formated
|
||||
the starting point for a simple class which can be used to log formatted
|
||||
output. See the implementation of a <a href="simple_log.html">simple
|
||||
log archive</a> to how this has been done.
|
||||
|
||||
<h3><a name="implementation">More Useful Archive Classes</a></h3>
|
||||
The above example is fine as far as it goes. But it doesn't implement
|
||||
useful features such as serialization of pointers, class versioning
|
||||
and others. This library implements a family of full featuared archive
|
||||
and others. This library implements a family of full featured archive
|
||||
classes appropriate for a variety of purposes.
|
||||
|
||||
<p>
|
||||
Our archives have been factored in to a tree of classes in order to minimize
|
||||
Our archives have been factored into a tree of classes in order to minimize
|
||||
repetition of code. This is shown in the accompanying
|
||||
<a target="class_diagram" href="class_diagram.html">class diagram</a>.
|
||||
|
||||
Any class which fullfills the following requirements will fit into
|
||||
Any class which fulfills the following requirements will fit into
|
||||
this hierarchy and implement all the features we require. Deriving from
|
||||
the base class <a href="../../../boost/archive/detail/common_oarchive.hpp" target="common_oarchive_hpp">
|
||||
common_oarchive.hpp</a> provides all features we desire which
|
||||
@@ -113,7 +113,7 @@ class complete_oarchive :
|
||||
friend class boost::archive::save_access;
|
||||
|
||||
// member template for saving primitive types.
|
||||
// Specialize for any types/templates that special treatment
|
||||
// Specialize for any types/templates that require special treatment
|
||||
template<class T>
|
||||
void save(T & t);
|
||||
|
||||
@@ -144,7 +144,7 @@ to help render the archive in a particular form.
|
||||
<dd>
|
||||
<strong>Default</strong>:Does nothing.<br>
|
||||
<strong>Purpose</strong>:To inject/retrieve an object name into the archive. Used
|
||||
by XML archive to inject "<name " before data.
|
||||
by XML archive to inject "<name>" before data.
|
||||
</dd>
|
||||
<p>
|
||||
|
||||
@@ -161,12 +161,12 @@ by XML archive to inject "</name>" after data.
|
||||
<strong>Default</strong>:Does nothing.<br>
|
||||
<strong>Purpose</strong>:Called <strong>each time</strong> user data is saved.
|
||||
It's not called when archive bookkeeping data is saved. This is used by XML archives
|
||||
to determine when to inject a ">" character at end of XML header. XML output archives
|
||||
to determine when to inject a ">" character at the end of an XML header. XML output archives
|
||||
keep their own internal flag indicating that data being written is header data. This
|
||||
internal flag is reset when an object start tag is written. When
|
||||
<code style="white-space: normal">void end_preamble()</code> is invoked and this internal flag is set
|
||||
a ">" character is appended to the output and the internal flag is reset. The default
|
||||
implementation for <code style="white-space: normal">void end_preamble()</code> is a no-op there by permitting it
|
||||
implementation for <code style="white-space: normal">void end_preamble()</code> is a no-op thereby permitting it
|
||||
to be optimised away for archive classes that don't use it.
|
||||
</dd>
|
||||
<p>
|
||||
@@ -183,7 +183,7 @@ name-value pairs by overriding this function template for name-value pairs.
|
||||
This replaces the default name-value pair handling, which is just to throw away the name,
|
||||
with one appropriate for XML which writes out the start of an XML tag with the correct object name.
|
||||
<p>
|
||||
The second argument must be part of the function signature even this it is not used.
|
||||
The second argument must be part of the function signature even though it is not used.
|
||||
Its purpose is to be sure that code is portable to compilers which fail to correctly
|
||||
implement partial function template ordering. For more information see
|
||||
<a href="implementation.html#functiontemplateordering">this</a>.
|
||||
@@ -242,7 +242,7 @@ One or more of the following issues may need to be addressed:
|
||||
example, XML archives need <name ... >...</name> surrounding
|
||||
all data objects.
|
||||
<li>Addressing any of the above may generate more issues to be addressed.
|
||||
<li>The archives included with library are all templates which use a
|
||||
<li>The archives included with the library are all templates which use a
|
||||
<code style="white-space: normal">stream</code> or
|
||||
<code style="white-space: normal">streambuf</code>
|
||||
as a template parameter rather than simple classes.
|
||||
@@ -281,7 +281,7 @@ exception.
|
||||
Exhaustive testing of the library requires testing the different aspects of object
|
||||
serialization with each archive. There are 46 different tests that can run with any archive.
|
||||
There are 5 "standard archives" included with the system.
|
||||
(3 in systems don't support wide charactor i/o).
|
||||
(3 in systems that don't support wide charactor i/o).
|
||||
<p>
|
||||
In addition, there are 28 other tests which aren't related to any particular archive class.
|
||||
<p>
|
||||
@@ -354,7 +354,7 @@ each time a new archive class is created.
|
||||
</ul>
|
||||
|
||||
<h4>Implementation</h4>
|
||||
The solution is the the pair <code>polymorphic_oarchive</code>
|
||||
The solution is the pair <code>polymorphic_oarchive</code>
|
||||
and <code>polymorphic_iarchive</code>. They present a common interface of virtual
|
||||
functions - no templates - that is equivalent to the standard templated one.
|
||||
|
||||
@@ -371,7 +371,7 @@ show how polymorphic archives are to be used. Note the following:
|
||||
<li><a target=demo_polymorphic_A_hpp href="../example/demo_polymorphic_A.hpp"><code style="white-space: normal">demo_polymorphic_A.hpp</code></a> and
|
||||
<a target=demo_polymorphic_A_cpp href="../example/demo_polymorphic_A.cpp"><code style="white-space: normal">demo_polymorphic_A.cpp</code></a>
|
||||
contain no templates and no reference to any specific archive implementation. That is, they will
|
||||
only have to be compiled once for all archive implementations. The even applies to archives classes
|
||||
only have to be compiled once for all archive implementations. This even applies to archives classes
|
||||
created in the future.
|
||||
<li>The main program <a target=demo_polymorphic_cp href="../example/demo_polymorphic.cpp"><code style="white-space: normal">demo_polymorphic.cpp</code></a>
|
||||
specifies a specific archive implementation.
|
||||
@@ -389,7 +389,7 @@ As these contain no code specific to the particular implementation archive, they
|
||||
a polymorphic archive implementation from any functioning templated archive implementation.
|
||||
<p>
|
||||
As a convenience, small header files have been included which contain
|
||||
<code style="white-space: normal">typedef</code> for polymorphic implementation for each corresponding
|
||||
a <code style="white-space: normal">typedef</code> for a polymorphic implementation for each corresponding
|
||||
templated one. For example, the headers
|
||||
<a target=polymorphic_text_iarchive_hpp href="../../../boost/archive/polymorphic_text_iarchive.hpp"><code style="white-space: normal">polymorphic_text_iarchive.hpp</code></a>
|
||||
and
|
||||
@@ -410,8 +410,8 @@ dispatch table and there is no possibility for a compiler to <code style="white-
|
||||
archive functions. This will result in a detectable degradation in performance for
|
||||
saving and loading archives.
|
||||
<p>
|
||||
Note this the concept and of polymophic archives is fundamentally incompatible with the
|
||||
serialization of new types are are marked "primitive" by the user with:
|
||||
Note that the concept of polymophic archives is fundamentally incompatible with the
|
||||
serialization of new types that are marked "primitive" by the user with:
|
||||
<pre><code>
|
||||
BOOST_CLASS_IMPLEMENTATION(my_primitive_type, boost::serialization::primitive_type)
|
||||
</code></pre>
|
||||
@@ -422,7 +422,7 @@ serialize such a primitive type will result in a compilation error since the com
|
||||
interface is static and cannot instantiate code for a new type.
|
||||
|
||||
<p>
|
||||
The main utility of polymorphic archives will be to permit the buiding of class DLLs that will
|
||||
The main utility of polymorphic archives will be to permit the building of class DLLs that will
|
||||
include serialization code for all present and future archives with no redundant code.
|
||||
<hr>
|
||||
<p><i>© Copyright <a href="http://www.rrsd.com">Robert Ramey</a> 2002-2004.
|
||||
|
||||
@@ -399,7 +399,7 @@ above.
|
||||
</code></h4></dt>
|
||||
<dd>
|
||||
Destructor for an archive. This should be called before the stream is
|
||||
closed. It restores any altered stream facets to thier state before the
|
||||
closed. It restores any altered stream facets to their state before the
|
||||
the archive was opened.
|
||||
</dd>
|
||||
</dl>
|
||||
|
||||
@@ -46,13 +46,13 @@ http://www.boost.org/LICENSE_1_0.txt)
|
||||
<a name="7"></a>
|
||||
<li>Alexandrescu, Andrei, <u>Modern C++ Design</u>, Addison-Wesley, 2001
|
||||
<a name="8"></a>
|
||||
<li>Jm Hyslop, and Herb Sutter, "Factory Redux, Part2",
|
||||
<li>Jim Hyslop, and Herb Sutter, "Factory Redux, Part2",
|
||||
<u>C/C++ User's Journal</u>, vol 21, No. 8, August 2003
|
||||
<a name="9"></a>
|
||||
<li>David Vandevoorde and Nicolai M. Josuttis,
|
||||
<u>C++ Templates - The Complete Guide</u>, Addison-Wesley, 2003
|
||||
<a name="10"></a>
|
||||
<li>Herb Sutter, "Pimples--Beauty Marks You Can Depend On",
|
||||
<li>Herb Sutter, "Pimpls--Beauty Marks You Can Depend On",
|
||||
<u>C++ Report</u>, from <u>More C++ Gems</u>, Cambridge University Press, 2000
|
||||
<a name="11"></a>
|
||||
<li>James Coplien, "Curiously Recurring Template Patterns",
|
||||
@@ -63,7 +63,7 @@ http://www.boost.org/LICENSE_1_0.txt)
|
||||
<a name="13"></a>
|
||||
<li>Stephan Beal, "s11n serialization library", <a href="http://www.s11n.net">www.s11n.net</a>
|
||||
<a name="14"></a>
|
||||
<li>Vandervoorde and Josuttis, <b>C++ Templates - A Complete Guide</b>, Addison-Wesley, 2003</a>
|
||||
<li>Vandevoorde and Josuttis, <b>C++ Templates - A Complete Guide</b>, Addison-Wesley, 2003</a>
|
||||
</ol>
|
||||
<hr>
|
||||
<p><i>© Copyright <a href="http://www.rrsd.com">Robert Ramey</a> 2002-2004.
|
||||
|
||||
@@ -42,7 +42,7 @@ template<
|
||||
<h2>Rationale</h2>
|
||||
|
||||
|
||||
UTF-8 is a method of encoding Unicode text in environments where
|
||||
UTF-8 is a method of encoding Unicode text in environments
|
||||
where data is stored as 8-bit characters and some ascii characters
|
||||
are considered special (i.e. Unix filesystem filenames) and tend
|
||||
to appear more commonly than other characters. While
|
||||
@@ -88,7 +88,7 @@ template<
|
||||
<h2>Requirements</h2>
|
||||
|
||||
<tt>utf8_codecvt_facet</tt> defaults to using <tt>char</tt> as
|
||||
it's external data type and <tt>wchar_t</tt> as it's internal
|
||||
its external data type and <tt>wchar_t</tt> as its internal
|
||||
datatype, but on some architectures <tt>wchar_t</tt> is
|
||||
not large enough to hold UCS-4 characters. In order to use
|
||||
another internal type.You must also specialize <tt>std::codecvt</tt>
|
||||
|
||||
@@ -35,19 +35,19 @@ We would prefer the solution that is:
|
||||
<ul>
|
||||
<li>Decomposable. so we can code, test, verify and use each (simple) stage of the conversion
|
||||
independently.
|
||||
<li>Composable. so we can used this composite as a new component somewhere else.
|
||||
<li>Composable. so we can use this composite as a new component somewhere else.
|
||||
<li>Efficient, so we're not required to re-implement it again.
|
||||
<li>Scalable, so that it works well for short and arbitrarily long sequences.
|
||||
</ul>
|
||||
The approach that comes closest to meeting these requirements is that described
|
||||
and implemented with <a href="../../iterator/doc/index.html">Iterator Adaptors</a>.
|
||||
The fundamental feature of an Iterator Adaptor template that makes in interesting to
|
||||
The fundamental feature of an Iterator Adaptor template that makes it interesting to
|
||||
us is that it takes as a parameter a base iterator from which it derives its
|
||||
input. This suggests that something like the following might be possible.
|
||||
<pre><code>
|
||||
typedef
|
||||
insert_linebreaks< // insert line breaks every 76 characters
|
||||
base64_from_binary< // convert binary values ot base64 characters
|
||||
base64_from_binary< // convert binary values to base64 characters
|
||||
transform_width< // retrieve 6 bit integers from a sequence of 8 bit bytes
|
||||
const char *,
|
||||
6,
|
||||
@@ -71,12 +71,12 @@ included is <a target="transform_iterator" href="../../iterator/doc/transform_it
|
||||
transform_iterator</a>, which can be used to implement 6 bit integer => base64 code.
|
||||
|
||||
<h3>Dataflow Iterators</h3>
|
||||
Unfortunately, not all iterators which inherit from Iterator Adaptors are guarenteed
|
||||
Unfortunately, not all iterators which inherit from Iterator Adaptors are guaranteed
|
||||
to meet the composability goals stated above. To accomplish this purpose, they have
|
||||
to be written with some additional considerations in mind.
|
||||
|
||||
We define a Dataflow Iterator as an class inherited from <code style="white-space: normal">iterator_adaptor</code> which
|
||||
fulfills as a small set of additional requirements.
|
||||
fulfills a small set of additional requirements.
|
||||
|
||||
<h4>Templated Constructors</h4>
|
||||
<p>
|
||||
@@ -110,12 +110,12 @@ std::copy(
|
||||
The recursive application of this template is what automatically generates the
|
||||
constructor <code style="white-space: normal">base64_text(const char *)</code> in our example above. The original
|
||||
Iterator Adaptors include a <code style="white-space: normal">make_xxx_iterator</code> to fulfill this function.
|
||||
However, I believe these are unwieldy to use compared to the above solution usiing
|
||||
However, I believe these are unwieldy to use compared to the above solution using
|
||||
Templated constructors.
|
||||
<p>
|
||||
Unfortunately, some systems which fail to properly support partial function template
|
||||
ordering cannot support the concept of a templated constructor as implemented above.
|
||||
A special"wrapper" macro has been created to work around this problem. With this "wrapper"
|
||||
A special "wrapper" macro has been created to work around this problem. With this "wrapper"
|
||||
the above example is modified to:
|
||||
<pre><code>
|
||||
std::copy(
|
||||
@@ -195,7 +195,7 @@ The standard stream iterators don't quite work for us. On systems which impleme
|
||||
as unsigned short integers (E.G. VC 6) they didn't function as I expected. I also made some
|
||||
adjustments to be consistent with our concept of Dataflow Iterators. Like the rest of our
|
||||
iterators, they are found in the namespace <code style="white-space: normal">boost::archive::interators</code> to avoid
|
||||
conflict the standard library version.
|
||||
conflicts with the standard library versions.
|
||||
<dl class = "index">
|
||||
<dt><a target="istream_iterator" href="../../../boost/archive/iterators/istream_iterator.hpp">
|
||||
istream_iterator</a></dt>
|
||||
|
||||
@@ -47,7 +47,7 @@ The serialization library is
|
||||
implemented using the <b>C</b>uriously <b>R</b>ecurring <b>T</b>emplate
|
||||
<b>P</b>attern (<b>CRTP</b>). Also, all common code is factored out into
|
||||
separate modules to minimize code repetition. This makes derivation from
|
||||
an existing archive less straight forward than it would otherwise be.
|
||||
an existing archive less straightforward than it would otherwise be.
|
||||
<p>
|
||||
This example illustrates several issues that have to be addressed when doing
|
||||
something like this
|
||||
@@ -84,13 +84,12 @@ the base classes.
|
||||
<li><i></i>Reread <a target="detail" href="headers.html#archiveinternals">Archive Internals</a>.
|
||||
This describes the class hierarchy so that you know what to override.
|
||||
<li><i>Note the usage of PFTO.</i> Some compilers fail to provide support for
|
||||
partial function template ordering. The serialization library works around by
|
||||
partial function template ordering. The serialization library works around this by
|
||||
using <a target="detail" href="implementation.html#functiontemplateordering">
|
||||
<b>P</b>artial <b>F</b>unction <b>T</b>emplate <b>O</b>rdering</a> in several places.
|
||||
In archive classes, this takes
|
||||
. This is done
|
||||
This is done
|
||||
in several places, including the archive classes themselves.
|
||||
<li><i>Base class functions will usually need to be explicitly invoked</i>
|
||||
<li><i>Base class functions will usually need to be explicitly invoked.</i>
|
||||
We commonly specialize the function name <code style="white-space: normal">save_override</code>
|
||||
for saving primitives. Usage of a function name in a derived class
|
||||
"hides" similarly named functions of the base class. That is,
|
||||
@@ -121,7 +120,7 @@ so it's what I use.
|
||||
</code></pre>
|
||||
for just this purpose. Failure to include required template definitions
|
||||
will result in undefined symbol errors when the program is linked.
|
||||
<li><i>Without alteration, this class cannot be further derived from</i><br>
|
||||
<li><i>Without alteration, this class cannot be further derived from.</i><br>
|
||||
Base classes using <b>CRTP</b> must be templates with a parameter corresponding to
|
||||
the most derived class. As presented here, this class doesn't qualify, so
|
||||
it cannot be used as a base class. In order to derive further from this class,
|
||||
@@ -136,7 +135,7 @@ class log_archive_impl :
|
||||
...
|
||||
);
|
||||
|
||||
// do not derived from this class !!!
|
||||
// do not derive from this class !!!
|
||||
class log_archive :
|
||||
public log_archive_impl<log_archive>
|
||||
{
|
||||
|
||||
@@ -70,7 +70,7 @@ an invalid pointer, or creating a memory leak.
|
||||
If an exception occurs, <i>referenced</i> pointers will not need to be deleted
|
||||
so there will be no memory leaks. The destructor of this class won't attempt to
|
||||
delete these pointers so there will be no problem with dangling references.
|
||||
<i>owned</i> pointers are handled exactly as described above.
|
||||
<i>Owned</i> pointers are handled exactly as described above.
|
||||
<p>
|
||||
<li><h4>class contains <i>referenced</i> pointers which might be created by load</h4>
|
||||
If a <i>referenced</i> pointer is loaded before its corresponding <i>owned</i>
|
||||
@@ -81,7 +81,7 @@ an invalid pointer, or creating a memory leak.
|
||||
<li>Trap exceptions with a <code style="white-space: normal">try/catch</code> block.
|
||||
<li>Within the catch part, invoke the archive function
|
||||
<code style="white-space: normal">delete_created_pointers()</code> to delete any pointers
|
||||
created by the class load. Without out other action, objects created in
|
||||
created by the class load. Without other action, objects created in
|
||||
this way would end up as memory leaks as they are not considered <i>owned</i>
|
||||
pointers and hence aren't destroyed.
|
||||
<li>The object's destructor won't try
|
||||
|
||||
@@ -57,7 +57,7 @@ class archive_exception : public std::exception
|
||||
{
|
||||
public:
|
||||
typedef enum {
|
||||
unregistered_class, // attempt to serialize a pointer of an
|
||||
unregistered_class, // attempt to serialize a pointer of
|
||||
// an unregistered class
|
||||
invalid_signature, // first line of archive does not contain
|
||||
// expected string
|
||||
@@ -66,8 +66,8 @@ public:
|
||||
pointer_conflict // an attempt has been made to directly serialize
|
||||
// an object after having already serialized the same
|
||||
// object through a pointer. Were this permitted,
|
||||
// it the archive load would result in the creation
|
||||
// of extraneous object.
|
||||
// the archive load would result in the creation
|
||||
// of an extraneous object.
|
||||
incompatible_native_format, // attempt to read native binary format
|
||||
// on incompatible platform
|
||||
array_size_too_short, // array being loaded doesn't fit in array allocated
|
||||
@@ -109,7 +109,7 @@ public:
|
||||
<h3><a name="unregistered_class"><code style="white-space: normal">unregistered_class</code></a></h3>
|
||||
An attempt has been made to serialize a polymorphic class through a pointer
|
||||
without either registering it or associating it with an export key. This can also occur
|
||||
when using a new archive how class name has not been added to the system with the
|
||||
when using a new archive whose class name has not been added to the system with the
|
||||
<code style="white-space: normal">BOOST_ARCHIVE_CUSTOM_ARCHIVE_TYPES</code> macro.
|
||||
|
||||
<h3><a name="invalid_signature"><code style="white-space: normal">invalid_signature</code></a></h3>
|
||||
@@ -121,7 +121,7 @@ exception is thrown.
|
||||
This system records the current library version number to all archives created. Note that this is in
|
||||
no way related to version number of classes used by application programs. This refers
|
||||
to the version of the serialization system used to create the archive. Future versions
|
||||
of this serialization system will be able to identify archives created under previous
|
||||
of this serialization system will be able to identify archives created under a previous
|
||||
(i.e. this) system and alter the loading procedure accordingly. Hence, future enhancements
|
||||
to this serialization system should not obsolete any existing archive files. It is only
|
||||
necessary to increment this version number when the newer system creates archives
|
||||
@@ -225,7 +225,7 @@ This, in turn, can result in the throwing of this exception.
|
||||
|
||||
<h3><a name="invalid_class_name"><code style="white-space: normal">invalid_class_name</code></a></h3>
|
||||
Class name length greater than the maximum permitted. Most likely cause is a corrupted
|
||||
archive or an attempt to insert virus via buffer overrun method.
|
||||
archive or an attempt to insert a virus via the buffer overrun method.
|
||||
|
||||
<h3><a name="unregistered_cast"><code style="white-space: normal">unregistered_cast</code></a></h3>
|
||||
In order to support casting between pointers of base and derived classes
|
||||
@@ -239,7 +239,7 @@ whose relationship has not been registered,
|
||||
|
||||
<h3><a name="multiple_code_instantiation"><code style="white-space: normal">multiple_code_instantiation</code></a></h3>
|
||||
This exception is thrown when it is detected that the serialization of the same type
|
||||
has been instantiated more that once. This might occur when
|
||||
has been instantiated more than once. This might occur when
|
||||
serialization code is instantiated in both the mainline and one or more DLLS.
|
||||
|
||||
<h3><a name="xml_archive_parsing_error"><code style="white-space: normal">xml_archive_parsing_error</code></a></h3>
|
||||
@@ -250,8 +250,8 @@ to the loading serialization and this exception might be thrown. This might
|
||||
occur for one of the following reasons:
|
||||
<ul>
|
||||
<li>The archive has been edited outside the serialization system. This might
|
||||
be possible if only the data is changed and not the XML attributes and nesting
|
||||
structure is left unaltered. But any other editing is likely to render the
|
||||
be possible if only the data is changed and the XML attributes and nesting
|
||||
structure are left unaltered. But any other editing is likely to render the
|
||||
archive unreadable by the serialization library.
|
||||
<li>The serialization has been altered and an archive generated by the old
|
||||
code is being read. That is, versioning has not been properly employed to
|
||||
@@ -259,7 +259,7 @@ properly deserialize previously created archives.
|
||||
</ul>
|
||||
|
||||
<h3><a name="xml_archive_tag_mismatch"><code style="white-space: normal">xml_archive_tag_mismatch</code></a></h3>
|
||||
This exception will be thrown if the start or end tag of and XML element doesn't match
|
||||
This exception will be thrown if the start or end tag of an XML element doesn't match
|
||||
the name specified for the object in the program.
|
||||
|
||||
<h3><a name="xml_archive_tag_name_error"><code style="white-space: normal">xml_archive_tag_name_error</code></a></h3>
|
||||
|
||||
@@ -57,14 +57,14 @@ the following functions
|
||||
and operating systems. This makes it unusable for support of portable archives.
|
||||
<li>
|
||||
Even if the type name string could somehow be made portable, there is no
|
||||
guarentee that class headers would be included in the same name space accross
|
||||
guarantee that class headers would be included in the same namespace accross
|
||||
different applications. In fact, including different headers in different
|
||||
name spaces is an accepted method used to avoid name space conflicts.
|
||||
namespaces is an accepted method used to avoid namespace conflicts.
|
||||
Thus the namespace::class_name can't be used as a key.
|
||||
<li>
|
||||
There exists the possibility that different classes use different type id
|
||||
mechanism. The class header might include this information. If we want to
|
||||
import class headers accross applications, its convenient that the type id
|
||||
mechanisms. The class header might include this information. If we want to
|
||||
import class headers accross applications, it's convenient that the type id
|
||||
mechanism support inter-operability accross different type id systems.
|
||||
</ul>
|
||||
<h3>Features</h3>
|
||||
@@ -135,7 +135,7 @@ instance created for each type. However, this is enforced only at the executabl
|
||||
module level. That is, if a program includes some shared libraries or DLLS,
|
||||
there may be more than one instance of this class correponding to a particular type.
|
||||
For this reason the comparison functions below can't just compare the addresses of
|
||||
this instance but rather must be programmed to compare the the actual information
|
||||
this instance but rather must be programmed to compare the actual information
|
||||
the instances contain.
|
||||
<dl>
|
||||
|
||||
@@ -193,7 +193,7 @@ bool operator==(const extended_type_info & rhs) const;
|
||||
bool operator!=(const extended_type_info & rhs) const;
|
||||
</code></pre></h4></dt>
|
||||
<dd>
|
||||
These functions are used to compare 'wo
|
||||
These functions are used to compare
|
||||
<a target="extended_type_info.hpp" href = "../../../boost/serialization/extended_type_info.hpp">
|
||||
<code style="white-space: normal">
|
||||
extended_type_info
|
||||
@@ -213,7 +213,7 @@ Construct a new instance of the type to which this
|
||||
extended_type_info
|
||||
</code>
|
||||
</a>
|
||||
record corresponds. This function takes variable list of up to 4 arguments
|
||||
record corresponds. This function takes a variable list of up to 4 arguments
|
||||
of any type. These arguments are passed to the type's constructor
|
||||
at runtime. In order to use the facility,
|
||||
one must declare a type sequence for the constructor arguments.
|
||||
@@ -223,8 +223,8 @@ This function permits one to create instances of
|
||||
any exported type given only the exported <strong>GUID</strong> assigned
|
||||
with BOOST_CLASS_EXPORT.
|
||||
If these types are defined in DLLS or shared libraries. When these modules
|
||||
are loaded at runtime, these constructor can be called until the module
|
||||
is unloaded. These modules are referred to as <b>plugin</b>.
|
||||
are loaded at runtime, these constructors can be called until the module
|
||||
is unloaded. These modules are referred to as <b>plugins</b>.
|
||||
</code>
|
||||
</dd>
|
||||
|
||||
@@ -245,7 +245,7 @@ object.
|
||||
|
||||
</dl>
|
||||
|
||||
<h3><a name="requirements">Requirements for and Implementation</a></h3>
|
||||
<h3><a name="requirements">Requirements for an Implementation</a></h3>
|
||||
In order to be used by the serialization library, an implementation of
|
||||
<code style="white-space: normal">extended_type_info</code>,
|
||||
(referred to as ETI here), must be derived from
|
||||
@@ -348,7 +348,7 @@ The test program <code style="white-space: normal"><a target="test_no_rtti" href
|
||||
implements this function in terms of the <code style="white-space: normal"><a target="extended_type_info_no_rtti.hpp" href="../../../boost/serialization/extended_type_info_no_rtti.hpp">
|
||||
extended_type_info</a></code> API above to return the export key associated with the class.
|
||||
This requires that non-abstract types be exported. It also demonstrates the
|
||||
inter-operability with between two different implementations of
|
||||
inter-operability between two different implementations of
|
||||
<code style="white-space: normal">extended_type_info</code>.
|
||||
|
||||
<h3><a name="type_requirements">Requirements for Each Type</a></h3>
|
||||
|
||||
@@ -29,10 +29,10 @@ http://www.boost.org/LICENSE_1_0.txt)
|
||||
</tr>
|
||||
</table>
|
||||
<hr>
|
||||
This section will be used to list answers to questions raise in the mailing
|
||||
This section will be used to list answers to questions raised in the mailing
|
||||
lists. Most of these are due to subtle aspects of the library which are
|
||||
overlooked even though they might be described in the documenation. Often,
|
||||
these issues are very easy to address - but can be excruciating difficult to
|
||||
overlooked even though they might be described in the documentation. Often,
|
||||
these issues are very easy to address - but can be excruciatingly difficult to
|
||||
find. Should you have such an experience, feel free to vent your frustration
|
||||
in a constructive way by adding in your own item. The best way to do this
|
||||
is to create a <a href="http://svn.boost.org/trac/boost/browser">"TRAK" item</a>
|
||||
|
||||
@@ -42,10 +42,10 @@ http://www.boost.org/LICENSE_1_0.txt)
|
||||
</dl>
|
||||
</dl>
|
||||
|
||||
This library includes a large number of files. The are organized and classified
|
||||
according to purpose listed in the above index.
|
||||
This library includes a large number of files. They are organized and classified
|
||||
according to the purposes listed in the above index.
|
||||
<p>
|
||||
<code style="white-space: normal">namespace</code> of a classes and templates is syncronized
|
||||
<code style="white-space: normal">namespace</code> of classes and templates is synchronized
|
||||
with the directory in which the file is found. For example, the class declaration
|
||||
<pre><code>
|
||||
boost::archive::text_oarchive
|
||||
@@ -95,7 +95,7 @@ boost/archive/text_oarchive.hpp
|
||||
<dt><a target="text_wiarchive" href="../../../boost/archive/text_wiarchive.hpp">
|
||||
boost/archive/text_wiarchive.hpp
|
||||
</a>
|
||||
<dd>wide character text input archive used forloading.</dd>
|
||||
<dd>wide character text input archive used for loading.</dd>
|
||||
|
||||
<dt><a target="text_woarchive" href="../../../boost/archive/text_woarchive.hpp">
|
||||
boost/archive/text_woarchive.hpp
|
||||
@@ -207,7 +207,7 @@ This group of headers includes templates which implement serialization for Stand
|
||||
Library or Boost Library templates. Any program which uses these templates can
|
||||
invoke serialization of objects of these types just by including the corresponding header.
|
||||
<p>
|
||||
By convention' these header files are named:
|
||||
By convention these header files are named:
|
||||
|
||||
boost/serialization/xxx.hpp
|
||||
|
||||
@@ -257,7 +257,7 @@ for in all archive implementations. The serialization system relies on
|
||||
certain special types such as <code style="white-space: normal">class_id_type</code> and others to
|
||||
record information in archives that is required to reconstruct the original
|
||||
data structure. These are handled exactly as any other serializable type.
|
||||
That is, the can be handled as simple primitives such as they are in simple
|
||||
That is, they can be handled as simple primitives such as they are in simple
|
||||
text files, or with special code as they are in xml archives.
|
||||
</dd>
|
||||
|
||||
@@ -269,7 +269,7 @@ boost/archive/basic_text_iprimitive.hpp
|
||||
</a>
|
||||
</dt>
|
||||
<dd>
|
||||
Implementation of serialization of primitive types in terms of an character
|
||||
Implementation of serialization of primitive types in terms of character
|
||||
or wide character text streams. This is used in the implementation of text and
|
||||
xml archives. Presumably this would be useful for implementations of other variations
|
||||
of text archives such as user friendly text or windows ini files.
|
||||
@@ -283,7 +283,7 @@ boost/archive/basic_binary_iprimitive.hpp
|
||||
</a>
|
||||
</dt>
|
||||
<dd>
|
||||
Implementation of serialization of primitive types in terms of an character
|
||||
Implementation of serialization of primitive types in terms of character
|
||||
or wide character binary streams.
|
||||
</dd>
|
||||
|
||||
@@ -294,10 +294,10 @@ boost/archive/basic_binary_oarchive.hpp
|
||||
boost/archive/basic_binary_iarchive.hpp
|
||||
</a>
|
||||
<dd>
|
||||
Implementation of serialization of all types in terms of an character
|
||||
Implementation of serialization of all types in terms of character
|
||||
or wide character binary streams. This is factored out separately from the
|
||||
implementation of binary primitives above. This may facilitate the creation of
|
||||
other types of binary archives in the future. It also preserves analogy and symetry with
|
||||
other types of binary archives in the future. It also preserves analogy and symmetry with
|
||||
the rest of the library which aids in understanding.
|
||||
</dd>
|
||||
<dt><a target="basic_text_oarchive" href="../../../boost/archive/basic_text_oarchive.hpp">
|
||||
@@ -315,10 +315,10 @@ boost/archive/basic_xml_iarchive.hpp
|
||||
</a>
|
||||
</dt>
|
||||
<dd>
|
||||
Implementation of serialization of all types in terms of an character
|
||||
Implementation of serialization of all types in terms of character
|
||||
or wide character text streams. These classes specify archive type specific
|
||||
behavior on a type by type basis. For example, <code style="white-space: normal">basic_xml_oarchive.hpp</code>
|
||||
includes code to guarentee that any object not attached to a name will
|
||||
includes code to guarantee that any object not attached to a name will
|
||||
trap during compile time. On the other hand, <code style="white-space: normal">basic_text_oarchive.hpp</code>
|
||||
contains code to strip out and ingore any names attached to objects.
|
||||
<p>
|
||||
@@ -356,7 +356,7 @@ boost/archive/detail/interface_iarchive.hpp</a>
|
||||
<dt><a target="interface_iarchive" href="../../../boost/archive/detail/interface_iarchive.hpp">
|
||||
boost/archive/detail/interface_iarchive.hpp</a>
|
||||
<dd>
|
||||
Here are the declarations and definitions which for the
|
||||
Here are the declarations and definitions for the
|
||||
<a href="archives.html">archive_concept</a>. This class redirects calls to the
|
||||
archive interface to a function named <code>save_override</code> in the most derived
|
||||
archive class.
|
||||
@@ -403,7 +403,7 @@ library code for that part of the code which only depends upon the archive type.
|
||||
Building of the library generates and compiles code for all archives implemented.
|
||||
|
||||
<ul>
|
||||
<li>Serialization of user and primitive types runs a top speed. This is a noticiable
|
||||
<li>Serialization of user and primitive types runs at top speed. This is a noticeable
|
||||
difference with a previous version of the library which did not use templates for archives.
|
||||
<li>Library implementation code that never changes need only be compiled once
|
||||
rather than each time a user's program is recompiled. This can save much
|
||||
@@ -418,22 +418,22 @@ Building of the library generates and compiles code for all archives implemented
|
||||
</ul>
|
||||
An example of this is the usage of the spirit library in the library.
|
||||
It takes a long time to compile and includes lots of other files. Having this
|
||||
only in the library is much more convenient that having to include in every
|
||||
only in the library is much more convenient that having to include it in every
|
||||
program which uses xml serialization.
|
||||
|
||||
<a name="dataflowiterators">
|
||||
<h4>Dataflow Iterators</h4>
|
||||
In the course of developing this library, it became convenient to make a set
|
||||
of composable iterator adaptors for handling archive text. Applications include
|
||||
escaping and unescaping xml text, implementi'g to/from base64 conversion among
|
||||
escaping and unescaping xml text and implementing to/from base64 conversion among
|
||||
others.
|
||||
<p>
|
||||
This is a ripe topic in itself. Its touched upon by the
|
||||
This is a ripe topic in itself. It's touched upon by the
|
||||
<a href="../../../libs/iterator/doc/index.html">boost iterator</a> libraries,
|
||||
<a href="http://www.zib.de/weiser/vtl/index.html">View Template Library</a>, and others.
|
||||
<p>
|
||||
The code for these iterators is really independent of this library. But since it
|
||||
hasn't been and probably won't be reviewed outside of this context. I've left in a directory
|
||||
hasn't been and probably won't be reviewed outside of this context. I've left it in a directory
|
||||
local to the serialization library:
|
||||
<a target="archiveiterators" href="../../../boost/archive/iterators">boost/archive/iterators</a>.
|
||||
These iterators are described in
|
||||
|
||||
@@ -30,24 +30,24 @@ http://www.boost.org/LICENSE_1_0.txt)
|
||||
<li>27 Feb 2002
|
||||
<ul>
|
||||
<li>divide interface from implementation for class
|
||||
serialization to permit compiliation on gcc
|
||||
<li>improved template instantanciation for type templates
|
||||
serialization to permit compilation on gcc
|
||||
<li>improved template instantantation for type templates
|
||||
</ul>
|
||||
<li>18 Mar 2002 - draft #2 uploaded to boost
|
||||
<ul>
|
||||
<li>elminated locale effects on archives
|
||||
<li>added signature and library version to archive header
|
||||
<li>improved detection of errors when objects are serializationed
|
||||
as pointers and subsequently serializationed as objects
|
||||
<li>improved detection of errors when objects are serialized
|
||||
as pointers and subsequently serialized as objects
|
||||
<li>permit non-portable binary archives
|
||||
<li>implement work around for systems such as MSVC 6.0 that
|
||||
don'tsupport partial ordering
|
||||
<li>implement workaround for systems such as MSVC 6.0 that
|
||||
don't support partial ordering
|
||||
</ul>
|
||||
<li>16 May 2002 - draft #3 uploaded to boost
|
||||
<ul>
|
||||
<li>Ability to specify serialization of other templates in a
|
||||
non-intrusive way.
|
||||
<li>Included and example which uses boost::shared_ptr.
|
||||
<li>Included an example which uses boost::shared_ptr.
|
||||
<li>improved documentation
|
||||
<li>More test cases
|
||||
<li>More testing and documentation of obscure situtations
|
||||
@@ -65,7 +65,7 @@ http://www.boost.org/LICENSE_1_0.txt)
|
||||
<li>minor corrections
|
||||
<li>Additions to documentation to explicitly address issues of
|
||||
exception safety.
|
||||
<li>More test cases/demos to illustrate handlling of the above issues.
|
||||
<li>More test cases/demos to illustrate handling of the above issues.
|
||||
<li>Additions to documentation to include rationale for not depending
|
||||
on type_id
|
||||
<li>Implementation of serialization of boost::shared_ptr.
|
||||
@@ -128,7 +128,7 @@ http://www.boost.org/LICENSE_1_0.txt)
|
||||
<li>1 November 2004 - final changes for first boost official release 1.32 .
|
||||
<ul>
|
||||
<li>Adjustments to address make package compatible with two-phase lookup.
|
||||
<li>Many small adjustments to accomdate quirks of various compilers.
|
||||
<li>Many small adjustments to accommodate quirks of various compilers.
|
||||
<li>A few bug fixes.
|
||||
</ul>
|
||||
</ol>
|
||||
|
||||
@@ -128,7 +128,7 @@ void serialize(
|
||||
The whole question of character encoding combined with wide characters
|
||||
is much more complicated than it would seem to be. The current library
|
||||
defines in 3 formats (text, binary, and XML), wide and narrow characters,
|
||||
an attempts to be portable between compiler libraries. The results of
|
||||
and attempts to be portable between compiler libraries. The results of
|
||||
a rather long consideration of all these factors has been to set
|
||||
default encoding according to the following rules.
|
||||
<ul>
|
||||
@@ -149,7 +149,7 @@ default encoding according to the following rules.
|
||||
</ul>
|
||||
This character encoding is implemented by changing the <code style="white-space: normal">locale</code> of the
|
||||
i/o stream used by an archive when the archive is constructed, the stream
|
||||
local is changed back to its original value. This action can be overridden
|
||||
locale is changed back to its original value. This action can be overridden
|
||||
by specifying <code style="white-space: normal">boost::archive::no_codecvt</code>
|
||||
when the archive is opened. In this case, the stream <code style="white-space: normal">locale</code> will
|
||||
not be changed by the serialization library.
|
||||
@@ -177,7 +177,7 @@ do the following.
|
||||
Naturally, the input process has to be symmetrical.
|
||||
<h3><a name="partialtemplatespecialization">Partial Template Specialization</a></h3>
|
||||
Compilers which fail to support partial template specialization will fail to compile
|
||||
the following code. To make this compiler, the <code style="white-space: normal">const</code> has to be removed.
|
||||
the following code. To make this compile, the <code style="white-space: normal">const</code> has to be removed.
|
||||
<pre><code>
|
||||
void f(A const* a, text_oarchive& oa)
|
||||
{
|
||||
@@ -259,12 +259,12 @@ This is due to the way that VC++ handles templated code with __decl(dllexport) a
|
||||
__decl(dllimport) specifications. Basically, this compiler requires that all the
|
||||
instantiations have the same specification - even though they have different
|
||||
template arguments. The example <code style="white-space: normal">
|
||||
demo_portable_iarchive.cpp</code> would have to reformulated as a library or dll
|
||||
demo_portable_iarchive.cpp</code> would have to be reformulated as a library or dll
|
||||
similar to the pre-defined archives in order to function.
|
||||
<p>
|
||||
This compiler does not have RTTI or exception handling turned on by default. Although
|
||||
they are not strictly necessary to use the serialization package, the example and test
|
||||
program presume that they are enabled. So be sure your command line or IDE settings
|
||||
programs presume that they are enabled. So be sure your command line or IDE settings
|
||||
enable these features if you want to build and run these programs.
|
||||
<p>
|
||||
This compiler can treat <code style="white-space: normal">wchar_t</code> as either
|
||||
@@ -280,14 +280,14 @@ includes this switch by default. So if want to use the libraries that
|
||||
when you compile your own applications.
|
||||
<h5>Using the Visual C++ IDE</h5>
|
||||
The library includes a VC++ 7.1 "Solution" - <code style="white-space: normal">BoostSerializationLibrary</code>
|
||||
along with of a set of project files - one for each demo and test. Consider the following if you
|
||||
decided to use these configurations.
|
||||
along with a set of project files - one for each demo and test. Consider the following if you
|
||||
decide to use these configurations.
|
||||
<ul>
|
||||
<li>The projects assume that the tests have been built with bjam using the default
|
||||
locations. This will result in a <code style="white-space: normal">bin</code> subdirectory
|
||||
within one's main boost directory. Below this there is a whole structure which maintains
|
||||
object and library files according to the type of build. The easiest way to build this is to
|
||||
invoke the runtest script which uses bjam. (see below) If the libraries are not in these locations,
|
||||
invoke the runtest script which uses bjam (see below). If the libraries are not in these locations,
|
||||
the projects will have to be modified accordingly.
|
||||
<li>There are project configurations for all the combinations of build variants that boost
|
||||
supports. That is for release, debug, static, static multi-threading, etc..
|
||||
@@ -348,7 +348,7 @@ all the above issues for Visual C++ 7.0 plus:
|
||||
still demonstrate this facility.
|
||||
<li>This compiler does not support <code style="white-space: normal">wchar_t</code> as a separate type. It defines
|
||||
<code style="white-space: normal">wchar_t</code> as an alias for <code style="white-space: normal">short int</code>. In general things will still
|
||||
function. However certain customization, such as overloading archive operators for
|
||||
function. However certain customizations, such as overloading archive operators for
|
||||
saving/loading wide character arrays would produce surprises in this environment.
|
||||
<li>Under certain circumstances, a program will fail to link with the message:
|
||||
LIN1179 - "invalid or corrupt file: duplicate comdat". According
|
||||
@@ -383,7 +383,7 @@ all the above issues for Visual C++ 7.0 plus:
|
||||
Conversion to/from integers will work around the problem.
|
||||
<li>If class serialize functions are not accessible either by making them public or by
|
||||
including <code style="white-space: normal">friend</code> declarations as described in
|
||||
<a href="serialization.html#member">Class Serialization - Member Function</a>, the
|
||||
<a href="serialization.html#member">Class Serialization - Member Function</a>, the code
|
||||
will compile but fail at runtime.
|
||||
<li>Tests using custom extended type which doesn't use RTTI fails. (5.64 only !).
|
||||
<li>Tests built in release mode fail. This seems to be an issue with the boost test system
|
||||
@@ -402,7 +402,7 @@ all the above issues for Visual C++ 7.0 plus:
|
||||
|
||||
<h4><a name="codewarrior9">Code Warrior 9.x</a></h4>
|
||||
<ul>
|
||||
<li>Some tests and demos demos fail - still under investigation
|
||||
<li>Some tests and demos fail - still under investigation
|
||||
</ul>
|
||||
|
||||
<h4><a name="codewarrior">Code Warrior 8.3</a></h4>
|
||||
@@ -422,7 +422,7 @@ Several compilers, including Visual C++ 6.0, use an older dinkumware library.
|
||||
These platforms have several issues:
|
||||
<ul>
|
||||
<li>The dinkumware library shipped with this compiler does not change the locale facet
|
||||
of an i/o stream unless the <code style="white-space: normal">imbue</code> function is called before the the
|
||||
of an i/o stream unless the <code style="white-space: normal">imbue</code> function is called before the
|
||||
stream is opened. In order to use this library with this environment to generate UTF-8
|
||||
files, one cannot depend on the "automatic" setting of locale that archives implement. The
|
||||
stream locale must be set explicitly on the stream before an archive is opened on it. The
|
||||
@@ -434,7 +434,7 @@ These platforms have several issues:
|
||||
|
||||
<h4><a name="stlport">STLPort 4.5.3</a></h4>
|
||||
<ul>
|
||||
<li>when built to use dynamic linking versions of C++ runtime code (<runtime-link>dynamic)
|
||||
<li>when built to use the dynamic linking versions of the C++ runtime code (<runtime-link>dynamic)
|
||||
all tests fail to link. This is due to a missing symbol in the stlport library related
|
||||
to custom codecvt facets.
|
||||
<li>the test_set fails to run correctly. It seems the hashed set iterator doesn't
|
||||
|
||||
@@ -36,13 +36,13 @@ techiques on how to use the library to address specific situations.
|
||||
|
||||
<h2><a name="functionobject"></a>Serializing a Function Object</h2>
|
||||
An example on how to serialize a function object. I believe this
|
||||
could be done by serializing pointer to the object in question. Since
|
||||
the Serialization library resurrects pointer of the correct type
|
||||
could be done by serializing a pointer to the object in question. Since
|
||||
the Serialization library resurrects a pointer of the correct type
|
||||
this should be easily implementable.
|
||||
<p>
|
||||
If a group of function objects were all derived from the
|
||||
same polymorphic base class - perhaps via multiple inheritance,
|
||||
the the function object effectively becomes a "variable" which
|
||||
then the function object effectively becomes a "variable" which
|
||||
encapsulates code.
|
||||
<p>
|
||||
This case study would show how to do this.
|
||||
@@ -51,19 +51,19 @@ This case study would show how to do this.
|
||||
|
||||
Often users want to add their own special functionality to an
|
||||
existing archive. Examples of this are performance enhancements
|
||||
for specific types, Adjustment of output syntax for xml archives,
|
||||
for specific types, adjustment of output syntax for xml archives,
|
||||
and logging/debug output as archives are written and/or read.
|
||||
If this functionalty is implemented as an "adaptor" template
|
||||
which takes the base class as a template argument, such functionality
|
||||
appended to any archive for which that funtionality makes sense.
|
||||
If this functionality is implemented as an "adaptor" template
|
||||
which takes the base class as a template argument, such functionality could be
|
||||
appended to any archive for which that functionality makes sense.
|
||||
For example, an adaptor for generating an xml schema could be
|
||||
appended to both wide narrow character versions of xml archives.
|
||||
appended to both wide and narrow character versions of xml archives.
|
||||
<p>
|
||||
This case study would show how to make a useful archive adaptor.
|
||||
|
||||
<h2><a name="archivehelper"></a>Archive Helpers</h2>
|
||||
Some types are not serializable as they stand. That is - they
|
||||
do not fullfill the requirements of the "Serializable Concept".
|
||||
do not fulfill the requirements of the "Serializable Concept".
|
||||
The iconic example of this is boost::shared_ptr. Sometimes
|
||||
these types could be made serializable by adding code inside
|
||||
the library. Of course, doing that would create a lifetime
|
||||
|
||||
@@ -31,7 +31,7 @@ the "Handle Body Idiom". Included in this library is a program called
|
||||
<a href="../example/demo_pimpl.cpp" target="demo_impl_cpp">demo_pimpl.cpp</a>
|
||||
which illustrates how this is used. The file
|
||||
<a href="../example/demo_pimpl_A.cpp" target="demo_impl__Acpp">demo_pimpl_A.hpp</a>
|
||||
contains the declaration of the a class that hides its implementation
|
||||
contains the declaration of the A class that hides its implementation
|
||||
by including a pointer to struct B that is only defined as a pointer.
|
||||
<pre><code>
|
||||
// class whose declaration is hidden by a pointer
|
||||
@@ -90,7 +90,7 @@ void A::serialize(boost::archive::text_iarchive & ar, const unsigned int file_ve
|
||||
</code></pre>
|
||||
The problem is that when compiling the above code,
|
||||
there is no instantiation of the <code style="white-space: normal">serialize</code> template.
|
||||
There can't be as its not "known" what types of archives
|
||||
There can't be as it's not "known" what types of archives
|
||||
the serialization is going to be used with. So these functions are "missing"
|
||||
when an attempt to link is made. The solution is to explicitly instantiate
|
||||
serialization code for those archives which are going to be used. In this
|
||||
|
||||
@@ -49,7 +49,7 @@ 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 item 41 .
|
||||
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
|
||||
|
||||
@@ -136,7 +136,7 @@ be made accessible to the serialization library by including:
|
||||
friend class boost::serialization::access;
|
||||
</code></pre>
|
||||
in the class definition. This latter method should be preferred over the option
|
||||
of making member function public. This will prevent serialization functions from
|
||||
of making the member function public. This will prevent serialization functions from
|
||||
being called from outside the library. This is almost certainly an error. Unfortunately,
|
||||
it may appear to function but fail in a way that is very difficult to find.
|
||||
<p>
|
||||
@@ -196,7 +196,7 @@ templates can be in any of the following namespaces:
|
||||
Note that, at first glance, this suggestion may seem to be wrong for compilers which implement
|
||||
two phase lookup. In fact, the serialization library used a perhaps overly clever
|
||||
method to support this rule even for such compilers. Those with an interest in studying
|
||||
this furter will find more information in
|
||||
this further will find more information in
|
||||
<a target=serialization_hpp href="../../../boost/serialization/serialization.hpp">serialization.hpp</a>
|
||||
|
||||
<h3><a name="classmembers">Serialization of Class Members</a></h3>
|
||||
@@ -262,7 +262,7 @@ the question about what <code style="white-space: normal">const</code> means in
|
||||
of serialization.
|
||||
|
||||
<h4><a name="templates"></a>Templates</h4>
|
||||
Implementation serialization for templates is exactly the same process
|
||||
Implementation of serialization for templates is exactly the same process
|
||||
as for normal classes and requires no additional considerations. Among
|
||||
other things, this implies that serialization of compositions of templates
|
||||
are automatically generated when required if serialization of the
|
||||
@@ -273,7 +273,7 @@ class <code style="white-space: normal">my_t</code>, then serialization for
|
||||
<code style="white-space: normal">std::list< boost::shared_ptr< my_t> ></code> is already available
|
||||
for use.
|
||||
<p>
|
||||
See for an example that shows how this idea might be implemented for your own
|
||||
For an example that shows how this idea might be implemented for your own
|
||||
class templates, see
|
||||
<a href="../example/demo_auto_ptr.cpp" target="demo_auto_ptr.cpp">
|
||||
demo_auto_ptr.cpp</a>.
|
||||
@@ -434,7 +434,7 @@ is preferred. The key to the serialization implementation is that objects are s
|
||||
and loaded in exactly the same sequence. Using the <code style="white-space: normal">&</code>
|
||||
operator and <code style="white-space: normal">serialize</code>
|
||||
function guarantees that this is always the case and will minimize the
|
||||
occurence of hard to find errors related to synchronization of
|
||||
occurrence of hard to find errors related to synchronization of
|
||||
<code style="white-space: normal">save</code> and <code style="white-space: normal">load</code>
|
||||
functions.
|
||||
<p>
|
||||
@@ -482,7 +482,7 @@ Loading a pointer:
|
||||
<ol>
|
||||
<li>read a tag from the archive.
|
||||
<li>determine the type of object to be created
|
||||
<li>if the object has already been loaded, return it's address.
|
||||
<li>if the object has already been loaded, return its address.
|
||||
<li>otherwise, create a new instance of the object
|
||||
<li>read the data back in using the operators described above
|
||||
<li>return the address of the newly created object.
|
||||
@@ -496,7 +496,7 @@ and <code style="white-space: normal">>></code> operators
|
||||
<li>Loading the same pointer object multiple times
|
||||
results in only one object being created, thereby replicating
|
||||
the original pointer configuration.
|
||||
<li>Structures such as collections of polymorphic pointers,
|
||||
<li>Structures, such as collections of polymorphic pointers,
|
||||
are handled with no special effort on the part of users of this library.
|
||||
</ul>
|
||||
Serialization of pointers of derived types through a pointer to the
|
||||
@@ -907,11 +907,11 @@ rather than
|
||||
<pre><code>
|
||||
#include <list>
|
||||
</code></pre>
|
||||
Since the former includes the latter, this all that is necessary.
|
||||
Since the former includes the latter, this is all that is necessary.
|
||||
The same holds true for all STL collections as well as templates
|
||||
required to support them (e.g. <code style="white-space: normal">std::pair</code>).
|
||||
<p>
|
||||
As of this writing, the library contains serialization of the following boost clases:
|
||||
As of this writing, the library contains serialization of the following boost classes:
|
||||
<ul>
|
||||
<li>optional
|
||||
<li>variant
|
||||
|
||||
@@ -121,7 +121,7 @@ the same pointer deserialzed above. Default object tracking will ensure
|
||||
that no more than one instance of the object is created and that the
|
||||
pointer returned by multiple deserializations are all the same. Hence,
|
||||
regardless of how many instances of <code style="white-space: normal">shared_ptr/shared_count</code>
|
||||
corresponding to a particular object are created, the will all point
|
||||
corresponding to a particular object are created, they will all point
|
||||
to the same object.
|
||||
<p>
|
||||
Since <code style="white-space: normal">sp_counted_base_impl<P, D></code> is derived from
|
||||
@@ -150,7 +150,7 @@ inline void serialize(
|
||||
){
|
||||
}
|
||||
</code></pre>
|
||||
It would seem we're done, running the test program,
|
||||
It would seem we're done, but running the test program,
|
||||
<a href="../example/demo_shared_ptr.cpp" target="demo_shared_ptr_cpp">
|
||||
demo_shared_ptr.cpp
|
||||
</a>,
|
||||
@@ -197,7 +197,7 @@ void_cast_register<
|
||||
boost::detail::sp_counted_base,
|
||||
>();
|
||||
</code></pre>
|
||||
and we don't have to include a trival serializer for <code style="white-space: normal">sp_counted_base</code>
|
||||
and we don't have to include a trival serializer for <code style="white-space: normal">sp_counted_base</code>.
|
||||
<p>
|
||||
Finally we need to specify name-value pair wrappers if we want to be able
|
||||
to use this serialization with XML archives.
|
||||
@@ -219,9 +219,9 @@ shared pointers:
|
||||
BOOST_SHARED_POINTER_EXPORT(T)
|
||||
BOOST_SHARED_POINTER_EXPORT_GUID(T, K)
|
||||
</pre></code>
|
||||
These are specialize versions of the macros used for exporting classes serialized through raw pointers.
|
||||
These are specialized versions of the macros used for exporting classes serialized through raw pointers.
|
||||
<p>
|
||||
Clearly, complete, correct and exception safe serialization of smart pointers is going to
|
||||
Clear, complete, correct and exception safe serialization of smart pointers is going to
|
||||
be a challenge. I hope that this implementation provides a useful
|
||||
starting point for such an effort.
|
||||
<hr>
|
||||
|
||||
@@ -25,7 +25,7 @@ http://www.boost.org/LICENSE_1_0.txt)
|
||||
</tr>
|
||||
</table>
|
||||
<hr>
|
||||
The purpose of this example help clarify the usage of the
|
||||
The purpose of this example is to help clarify the usage of the
|
||||
<a href="archives.html"><strong>Archive Concept</strong></a>
|
||||
so that one can implement his own archive classes.
|
||||
<a href="../example/simple_log_archive.hpp" target="simple_archive_hpp">
|
||||
|
||||
@@ -42,10 +42,10 @@ names to types and tables which relate base classes to derived
|
||||
classes. Construction, destruction and usage of these variables
|
||||
requires consideration of the following issues:
|
||||
<ul>
|
||||
<li>Some static data variables and constants entries refer to others.
|
||||
<li>Some static data variable and constant entries refer to others.
|
||||
The sequence of initialization cannot be arbitrary but must be in proper
|
||||
sequence.</li>
|
||||
<li>A number of static variables aren't referred explicitly and, without
|
||||
<li>A number of static variables aren't referred to explicitly and, without
|
||||
special precautions, will be stripped by most code optimizers</li>
|
||||
<li>Many of these variables are created by templates and special care must
|
||||
be taken to be sure that they are instantiated</li>
|
||||
@@ -61,7 +61,7 @@ This singleton implementation has the following features:
|
||||
<li>
|
||||
Any instance will be constructed before any attempt is made to access it.</li>
|
||||
<li>
|
||||
Any instance created with a template is guarenteed to be instantiated.
|
||||
Any instance created with a template is guaranteed to be instantiated.
|
||||
<li>
|
||||
Regardless of whether or not an instance has been explicitly
|
||||
referred to, it will not be stripped by the optimizer when the
|
||||
@@ -70,16 +70,16 @@ This singleton implementation has the following features:
|
||||
All instances are constructed before
|
||||
<code style="white-space: normal">main</code> is called
|
||||
regardless of where they might be referenced within the program.
|
||||
In a multi-tasking system, this guarentees that there will be no
|
||||
In a multi-tasking system, this guarantees that there will be no
|
||||
race conditions during the construction of any instance. No
|
||||
thread locking is required to guarentee this.
|
||||
thread locking is required to guarantee this.
|
||||
<li>
|
||||
The above implies that any <code style="white-space: normal">const</code>
|
||||
instances are thread-safe during the whole program. Again, no
|
||||
thread locking is required.
|
||||
<li>
|
||||
If a mutable instance is created, and such an instance is modified
|
||||
after main is called in a mult-threading system, there exists
|
||||
after main is called in a multi-threading system, there exists
|
||||
the possibility that a race condition will occur. The serialization
|
||||
library takes care that in the few places where a mutable
|
||||
singleton is required, it is not altered after
|
||||
@@ -141,13 +141,13 @@ singleton<T>
|
||||
</code>
|
||||
</a>, the type T must be default constructable.
|
||||
It doesn't require static variables - though it may have them.
|
||||
Since the library guarentees that only one instance of
|
||||
Since the library guarantees that only one instance of
|
||||
<a target="singleton.hpp" href = "../../../boost/serialization/singleton.hpp">
|
||||
<code style="white-space: normal">
|
||||
singleton<T>
|
||||
</code>
|
||||
</a>
|
||||
and all accesss is through the above static interface
|
||||
exists and all accesss is through the above static interface
|
||||
functions, common member functions of T become
|
||||
the functional equivalent of
|
||||
<code style="white-space: normal">static</code> functions.
|
||||
@@ -156,7 +156,7 @@ the functional equivalent of
|
||||
There are at least two different ways to use this class template.
|
||||
Both are used in the serialization library.
|
||||
<p>
|
||||
The first way is illustrated by and excerpt from the file
|
||||
The first way is illustrated by an excerpt from the file
|
||||
<code style="white-space: normal"><a target="extended_type_info" href="../src/extended_type_info.cpp">extended_type_info.cpp</a></code>.
|
||||
which contains the following code:
|
||||
|
||||
@@ -171,9 +171,9 @@ extended_type_info::key_register(const char *key) {
|
||||
}
|
||||
</code></pre>
|
||||
Just by referring to the singleton instance anywhere in the program
|
||||
will guarentee that one and only one instance for the specified
|
||||
will guarantee that one and only one instance for the specified
|
||||
type (<code style="white-space: normal">ktmap</code> in this example)
|
||||
will exist throughout the program. There is no need for anyother
|
||||
will exist throughout the program. There is no need for any other
|
||||
declaration or definition.
|
||||
<p>
|
||||
A second way is to use
|
||||
@@ -216,7 +216,7 @@ extended_type_info_typeid<T>::get_const_instance()
|
||||
</code></pre>
|
||||
|
||||
Again, including one or more of the above statements anywhere
|
||||
in the program will guarentee that one and only one instance
|
||||
in the program will guarantee that one and only one instance
|
||||
is created and referred to.
|
||||
|
||||
<h3><a name="multithreading">Multi-Threading</a></h3>
|
||||
@@ -224,10 +224,9 @@ This singleton CAN be safely used in multi-threading applications if one
|
||||
is careful follow a simple rule:
|
||||
<p>
|
||||
<b>Do not call get_mutable_instance when more than one thread is running!</b>
|
||||
<'>
|
||||
All singletons used in the serialization library follow this rule.
|
||||
In order to help detect accidental violations of this rule there
|
||||
exists an singleton lock/unlock functions.
|
||||
exist singleton lock/unlock functions.
|
||||
<pre><code>
|
||||
void boost::serialization::singleton_module::lock();
|
||||
void boost::serialization::singleton_module::unlock();
|
||||
@@ -241,7 +240,7 @@ alteration of static variables before
|
||||
<code style="white-space: normal">main</code> is called.
|
||||
The <code style="white-space: normal">lock()</code> and
|
||||
<code style="white-space: normal">unlock()</code> are "global"
|
||||
in they affect ALL the singletons defined by this template.
|
||||
in that they affect ALL the singletons defined by this template.
|
||||
All serialization tests invoke <code style="white-space: normal">lock()</code>
|
||||
at the start of the progam. For programs compiled in release
|
||||
mode these functions have no effect.
|
||||
|
||||
@@ -33,9 +33,9 @@ operators:
|
||||
<dt><code>static_cast<T *<>(U *)<br>static_cast<T &<>(U &)</code></dt>
|
||||
<dd>
|
||||
<ul>
|
||||
<li>required if neither T nor U are not polymorphic
|
||||
<li>required if neither T nor U are polymorphic
|
||||
<li>permitted in other cases.
|
||||
<li>fails to detect erroneas casts of polymophic pointers/references at runtime.
|
||||
<li>fails to detect erroneous casts of polymophic pointers/references at runtime.
|
||||
<li>does not permit "cross casting"
|
||||
<li>inline function calls can be optimized away during compile time.
|
||||
</ul>
|
||||
@@ -46,7 +46,7 @@ operators:
|
||||
<ul>
|
||||
<li>permitted if either T or U are polymorphic
|
||||
<li>prohibited in other cases.
|
||||
<li>throws exception on detecting erroneas casts of polymorphic pointers/references
|
||||
<li>throws exception on detecting erroneous casts of polymorphic pointers/references
|
||||
at runtime.
|
||||
<li>permits "cross casting"
|
||||
<li>cannot optimise inline virtual functions at compile time.
|
||||
@@ -91,14 +91,14 @@ template<class T>
|
||||
bool is_storable(T &t){
|
||||
// what type of cast to use here?
|
||||
|
||||
// this fails at compiler time when T == base2
|
||||
// this fails at compile time when T == base2
|
||||
// return static_cast<base1 &>(t).is_storable();
|
||||
|
||||
// this fails at compiler time when T == top
|
||||
// this fails at compile time when T == top
|
||||
// otherwise it works but cannot optimize inline function call
|
||||
// return dynamic_cast<base1 &>(t).is_storable();
|
||||
|
||||
// this always works - and is guarenteed to generate the fastest code !
|
||||
// this always works - and is guaranteed to generate the fastest code !
|
||||
return (boost::smart_cast_reference<base1 &>(t)).is_storable();
|
||||
}
|
||||
|
||||
@@ -121,7 +121,7 @@ The serialization library includes a mix of classes which use
|
||||
both static polymorphism (<strong>CRTP</strong>) and dynamic
|
||||
polymorphism via virtual functions. <code style="white-space: normal">smart_cast</code>
|
||||
was written to address the more problematic manifestations of the
|
||||
situation exmplified above.
|
||||
situation exemplified above.
|
||||
|
||||
<h3>Usage</h3>
|
||||
The following syntax is supported:
|
||||
@@ -134,14 +134,14 @@ Note that the above syntax doesn't include
|
||||
<pre><code>
|
||||
smart_cast<Target & >(Source & s)
|
||||
</code></pre>
|
||||
but the same functionality is supported the the following special syntax
|
||||
but the same functionality is supported with the following special syntax
|
||||
<pre><code>
|
||||
smart_cast_reference<Target &>(Source & s)
|
||||
</code></pre>
|
||||
|
||||
<h3>Requirements</h3>
|
||||
<code style="white-space: normal">smart_cast</code> can be used only on compilers that support partial
|
||||
template specialization or on types for which have be specified with the
|
||||
template specialization or on types for which the
|
||||
macro <code style="white-space: normal">
|
||||
BOOST_BROKEN_COMPILER_TYPE_TRAITS_SPECIALIZATION(<type>)</code>
|
||||
has been applied.
|
||||
|
||||
@@ -97,7 +97,7 @@ and a likely source of very subtle bugs.
|
||||
Unfortunately, implementation issues currently prevent the detection of this kind of
|
||||
error when the data item is wrapped as a name-value pair.
|
||||
<p>
|
||||
A similar problem can occur when different objects are loaded to and address
|
||||
A similar problem can occur when different objects are loaded to an address
|
||||
which is different from the final location:
|
||||
<pre><code>
|
||||
template<class Archive>
|
||||
@@ -112,7 +112,7 @@ void load(boost::basic_oarchive & ar, const unsigned int version) const
|
||||
</code></pre>
|
||||
In this case, the address of <code>x</code> is the one that is tracked rather than
|
||||
the address of the new item added to the set. Left unaddressed
|
||||
this will break the features that depend on tracking such as loading object through a pointer.
|
||||
this will break the features that depend on tracking such as loading an object through a pointer.
|
||||
Subtle bugs will be introduced into the program. This can be
|
||||
addressed by altering the above code thusly:
|
||||
|
||||
@@ -137,7 +137,7 @@ values are duplicated, overhead associated with object tracking can
|
||||
be eliminated by setting the object tracking class serialization trait
|
||||
appropriately.
|
||||
<p>
|
||||
By default, data types designated primitive by
|
||||
By default, data types designated primitive by the
|
||||
<a target="detail" href="traits.html#level">Implementation Level</a>
|
||||
class serialization trait are never tracked. If it is desired to
|
||||
track a shared primitive object through a pointer (e.g. a
|
||||
@@ -236,7 +236,7 @@ in this manner comes at a cost. Once archives are released to users, the
|
||||
class serialization traits cannot be changed without invalidating the old
|
||||
archives. Including the class information in the archive assures us
|
||||
that they will be readable in the future even if the class definition
|
||||
is revised. A light weight structure such as display pixel might be
|
||||
is revised. A light weight structure such as a display pixel might be
|
||||
declared in a header like this:
|
||||
|
||||
<pre><code>
|
||||
@@ -264,14 +264,14 @@ BOOST_CLASS_TRACKING(pixel, boost::serialization::track_never)
|
||||
</code></pre>
|
||||
|
||||
<h3><a name="portability">Archive Portability</a></h3>
|
||||
Several archive classes create their data in the form of text or portable a binary format.
|
||||
It should be possible to save such an of such a class on one platform and load it on another.
|
||||
Several archive classes create their data in the form of text or a portable binary format.
|
||||
It should be possible to save such a class on one platform and load it on another.
|
||||
This is subject to a couple of conditions.
|
||||
<h4><a name="numerics">Numerics</a></h4>
|
||||
The architecture of the machine reading the archive must be able hold the data
|
||||
saved. For example, the gcc compiler reserves 4 bytes to store a variable of type
|
||||
<code style="white-space: normal">wchar_t</code> while other compilers reserve only 2 bytes.
|
||||
So its possible that a value could be written that couldn't be represented by the loading program. This is a
|
||||
So it's possible that a value could be written that couldn't be represented by the loading program. This is a
|
||||
fairly obvious situation and easily handled by using the numeric types in
|
||||
<a target="cstding" href="../../../boost/cstdint.hpp"><boost/cstdint.hpp></a>
|
||||
<P>
|
||||
@@ -356,7 +356,7 @@ not wrapped in a in a <a target="detail" href="wrappers.html#nvp">name-value pai
|
||||
be trapped at compile time. The system is implemented in such a way that for other archive classes,
|
||||
just the value portion of the data is serialized. The name portion is discarded during compilation.
|
||||
So by always using <a target="detail" href="wrappers.html#nvp">name-value pairs</a>, it will
|
||||
be guarenteed that all data can be serialized to all archive classes with maximum efficiency.
|
||||
be guaranteed that all data can be serialized to all archive classes with maximum efficiency.
|
||||
|
||||
<h3><a name="export">Exporting Class Serialization</a></h3>
|
||||
<a target="detail" href="traits.html#export">Elsewhere</a> in this manual, we have described
|
||||
@@ -371,7 +371,7 @@ requirement.
|
||||
In C++, usage of code not explicitly referred to is implemented via
|
||||
virtual functions. Hence, the need for export is implied by the
|
||||
usage of a derived class that is manipulated via a pointer or
|
||||
reference to it's base class.
|
||||
reference to its base class.
|
||||
|
||||
<p>
|
||||
<code style="white-space: normal">BOOST_CLASS_EXPORT</code> in the same
|
||||
@@ -383,7 +383,7 @@ archive class headers are included, then no code will be instantiated.
|
||||
<p>
|
||||
Note that the implemenation of this functionality requires
|
||||
that the <code style="white-space: normal">BOOST_CLASS_EXPORT</code>
|
||||
macro appear <b>after</b> and the inclusion of any archive
|
||||
macro appear <b>after</b> the inclusion of any archive
|
||||
class headers for which code is to be instantiated.
|
||||
So, code that uses <code style="white-space: normal">BOOST_CLASS_EXPORT</code>
|
||||
will look like the following:
|
||||
@@ -396,7 +396,7 @@ will look like the following:
|
||||
BOOST_CLASS_EXPORT(a)
|
||||
... // other class headers and exports
|
||||
</code></pre>
|
||||
This will be true regardless of whether the is part
|
||||
This will be true regardless of whether the code is part
|
||||
of a stand alone executable, a static library or
|
||||
a dyanmic or shared library.
|
||||
<p>
|
||||
@@ -425,14 +425,14 @@ one can include headers for just the
|
||||
<p>
|
||||
Strictly speaking, export should not be necessary if all pointer serialization
|
||||
occurs through the most derived class. However, in order to detect
|
||||
what would be catastophic error, the library traps ALL serializations through
|
||||
a pointer to a polymorphic which are not exported or otherwise registered.
|
||||
what would be a catastophic error, the library traps ALL serializations through
|
||||
a pointer to a polymorphic class which are not exported or otherwise registered.
|
||||
So, in practice, be prepared to register or export all classes with one
|
||||
or more virtual functions which are serialized through a pointer.
|
||||
|
||||
<p>
|
||||
Note that the implementation of this functionality depends upon vendor
|
||||
specific extensions to the C++ language. So, there is no guarenteed portability
|
||||
specific extensions to the C++ language. So, there is no guaranteed portability
|
||||
of programs which use this facility. However, all C++ compilers which
|
||||
are tested with boost provide the required extensions. The library
|
||||
includes the extra declarations required by each of these compilers.
|
||||
@@ -442,7 +442,7 @@ these extensions or something equivalent.
|
||||
<h3><a name="static_libraries">Static Libraries and Serialization</a></h3>
|
||||
Code for serialization of data types can be saved in libraries
|
||||
just as it can for the rest of the type implementation.
|
||||
This works well, and can save huge amount of compilation time.
|
||||
This works well, and can save a huge amount of compilation time.
|
||||
<ul>
|
||||
<li>Only compile serialization definitions in the library.
|
||||
<li>Explicitly instantiate serialization code for ALL
|
||||
@@ -518,9 +518,9 @@ guidelines:
|
||||
<li>Don't include <code>inline</code> code in classes used in DLLS.
|
||||
This will generate duplicate code in the DLLS and mainline. This
|
||||
needlessly duplicates code. Worse, it makes is possible for
|
||||
different versions of the same code exist simultaneously. This
|
||||
different versions of the same code to exist simultaneously. This
|
||||
type of error turns out to be excruciatingly difficult to debug.
|
||||
Finally, it opens the possibility that module being referred to
|
||||
Finally, it opens the possibility that a module being referred to
|
||||
might be explictly unloaded which would (hopefully) result in
|
||||
a runtime error. This is another bug that is not always
|
||||
reproducible or easy to find. For class member templates use something like
|
||||
@@ -547,16 +547,16 @@ template myclass::serialize(boost::archive::text_iarchive & ar, const unsigned i
|
||||
</code></pre>
|
||||
in the implementation file. This will result in generation of all code
|
||||
required in only one place. The library does not detect this type of error for you.
|
||||
<li>If DLLS are to be loaded an unloaded explicitly (e.g. using <code>dlopen</code> in *nix or
|
||||
<li>If DLLS are to be loaded and unloaded explicitly (e.g. using <code>dlopen</code> in *nix or
|
||||
<code>LoadLibrary</code> in Windows). Try to arrange that they are unloaded in the reverse
|
||||
sequence. This should guarentee that problems are avoided even if the
|
||||
above guidline hasn't been followed.
|
||||
sequence. This should guarantee that problems are avoided even if the
|
||||
above guideline hasn't been followed.
|
||||
|
||||
</ul>
|
||||
|
||||
<h3><a name="plugins">Plugins</a></h3>
|
||||
In order to implement the library, various facilities for runtime
|
||||
manipulation of types are runtime were required. These
|
||||
manipulation of types at runtime were required. These
|
||||
are <a target="detail" href="extended_type_info.html"><code>extended_type_info</code></a>
|
||||
for associating classes with external identifying strings (<b>GUID</b>)
|
||||
and <a target="detail" href="void_cast.html"><code>void_cast</code></a>
|
||||
@@ -586,33 +586,33 @@ BOOST_CLASS_EXPORT(a)
|
||||
... // other class headers and exports
|
||||
</code></pre>
|
||||
|
||||
With this in place, one can construct, serialize and destroy
|
||||
about which only is know the <b>GUID</b> and a base class.
|
||||
With this in place, one can construct, serialize and destroy a class
|
||||
about which is known only the <b>GUID</b> and a base class.
|
||||
|
||||
|
||||
<h3><a name="multi_threading">Multi-Threading</a></h3>
|
||||
The fundamental purpose of serialization would conflict with multiple
|
||||
thread concurrently writing/reading from/to a single open archive instance.
|
||||
The library implementation presumes that the application avoids such an situtation.
|
||||
threads concurrently writing/reading from/to a single open archive instance.
|
||||
The library implementation presumes that the application avoids such a situtation.
|
||||
<p>
|
||||
However, Writing/Reading different archives simultaneously
|
||||
in different tasks is permitted as each archive instance is (almost)
|
||||
completely independent from any other archive instance. The only shared
|
||||
information are some type tables which have been implemented using a
|
||||
information is some type tables which have been implemented using a
|
||||
lock-free thread-safe
|
||||
<a target="detail" href="singleton.html">
|
||||
<code style="white-space: normal">singleton</code>
|
||||
</a>
|
||||
described elsewhere in this documentation.
|
||||
<p>
|
||||
This singleton implementation guarentees that all of this shared
|
||||
This singleton implementation guarantees that all of this shared
|
||||
information is initialized when the code module which contains
|
||||
them is loaded. The serialization library takes care to
|
||||
it is loaded. The serialization library takes care to
|
||||
ensure that these data structures are not subsequently
|
||||
modified. The only time there could be a problem would
|
||||
be if code is loaded/unloaded while another task is
|
||||
serializing data. This could only occur for types whose
|
||||
serialization is implemented in a dynamically loaded/unload DLL
|
||||
serialization is implemented in a dynamically loaded/unloaded DLL
|
||||
or shared library. So if the following is avoided:
|
||||
<ul>
|
||||
<li>Accessing the same archive instance from different tasks.
|
||||
|
||||
@@ -78,7 +78,7 @@ type but still of distinct type.
|
||||
|
||||
<h3>Implemenation</h3>
|
||||
<code style="white-space: normal">BOOST_STRONG_TYPEDEF</code> is a macro
|
||||
which generates a class named "name" wraps and instance of its
|
||||
which generates a class named "name" which wraps an instance of its
|
||||
primitive type and provides appropriate conversion operators in order
|
||||
to make the new type substitutable for the one that it wraps.
|
||||
|
||||
|
||||
@@ -43,13 +43,13 @@ Currently there is a portable binary archive in the examples directory.
|
||||
It is not regularly submitted to the exhaustive boost testing regimen
|
||||
but it is tested occasionally and has been used in production code.
|
||||
<p>
|
||||
Its missing the following:
|
||||
It's missing the following:
|
||||
<ul>
|
||||
<li>Addition of portable floating point types. This is not trivial. In addition to
|
||||
handling floating point types of varying sizes, It requires
|
||||
handling invalid floating point numbers (NaNs) in a portable manner.
|
||||
<li>Some way to test archive portability within the Boost testing regimen.
|
||||
<li>Integration into the Boost testing similar to the other archive classes.
|
||||
<li>Integration into the Boost testing regimen similar to the other archive classes.
|
||||
</ul>
|
||||
|
||||
<h2><a name="performancetesting"></a>Performance Testing and Profiling</h2>
|
||||
@@ -67,13 +67,13 @@ which shows the results of each test and links to the actual
|
||||
profile.
|
||||
<p>
|
||||
The first thing I did was include some of the serialization library tests.
|
||||
It became immediatly apparent that these tests were totally unsuitable
|
||||
It became immediately apparent that these tests were totally unsuitable
|
||||
for performance testing and that new tests needed to be written for this
|
||||
purpose. These tests would highlight the location of any performance
|
||||
bottlenecks in the serialization library. Whenever I've subjected my
|
||||
code in the past to this type of analysis, I've always been suprised
|
||||
code in the past to this type of analysis, I've always been surprised
|
||||
to find bottlenecks in totally unanticipated places and fixing those
|
||||
has always lead to large improvements in performance. I expect that
|
||||
has always led to large improvements in performance. I expect that
|
||||
this project would have a huge impact on the utility of the serialization
|
||||
library.
|
||||
|
||||
@@ -81,10 +81,10 @@ library.
|
||||
|
||||
It has been suggested that a useful feature of the library would be
|
||||
the ability to create "older versions" of archives. Currently,
|
||||
the library permits one make programs that are guarenteed
|
||||
the library permits one to make programs that are guaranteed
|
||||
the ability to load archives with classes of a previous version.
|
||||
But there is not way to save classes in accordance with a
|
||||
previous version. At first I dismissed this a a huge project
|
||||
But there is no way to save classes in accordance with a
|
||||
previous version. At first I dismissed this as a huge project
|
||||
with small demand. A cursory examination of the code revealed
|
||||
that this would not be very difficult. It would require some
|
||||
small changes in code and some additional tests. Also it
|
||||
|
||||
@@ -38,7 +38,7 @@ http://www.boost.org/LICENSE_1_0.txt)
|
||||
<dt><a href="#compiletime_messages">Compile Time Warnings and Errors</a>
|
||||
</dl>
|
||||
Serialization of data depends on the type of the data. For example, for
|
||||
primitive types such as an <code style="white-space: normal">int</code>, it wouldn't make sense to save
|
||||
primitive types such as <code style="white-space: normal">int</code>, it wouldn't make sense to save
|
||||
a version number in the archive. Likewise, for a data type that is never
|
||||
serialized through a pointer, it would (almost) never make sense to track
|
||||
the address of objects saved to/loaded from the archive as it will never
|
||||
@@ -232,12 +232,12 @@ statisfactory for our purposes for the following reasons:
|
||||
<li>There might be classes locally defined in different code modules
|
||||
that have the same name.
|
||||
<li>There might be classes with different names that we want to
|
||||
consider equivalent for purposes of of serialization.
|
||||
consider equivalent for purposes of serialization.
|
||||
</ul>
|
||||
<p>
|
||||
So in the serialization library, this is addressed by invoking
|
||||
<code style="white-space: normal">BOOST_CLASS_EXPORT_KEY2(my_class, "my_class_external_identifier")</code>
|
||||
in the header file which declares he class.
|
||||
in the header file which declares the class.
|
||||
In a large majority of applications, the class name works just fine
|
||||
for the external identifier string so the following short cut is
|
||||
defined -
|
||||
@@ -248,8 +248,8 @@ programs which do not use DLLS, one can specify
|
||||
<code style="white-space: normal">BOOST_CLASS_EXPORT(my_class)</code>
|
||||
or
|
||||
<code style="white-space: normal">BOOST_CLASS_EXPORT_GUID(my_class, "my_class_external_identifier")</code>
|
||||
in either he declaration header or definition. These macros
|
||||
expand to invocation of the of both of the macros described above.
|
||||
in either the declaration header or definition. These macros
|
||||
expand to invocation of both of the macros described above.
|
||||
<i>(<b>GUID</b> stands for <b>G</b>lobally <b>U</b>nique <b>ID</b>entfier.)</i>
|
||||
<p>
|
||||
<i>(<a target="detail" href="special.html#export">Elsewhere</a>
|
||||
@@ -267,7 +267,7 @@ in more than one module (or DLL).
|
||||
|
||||
<h3><a name="abstract">Abstract</a></h3>
|
||||
When serializing an object through a pointer to its base class,
|
||||
the library needs to determine whether or not the bas is abstract
|
||||
the library needs to determine whether or not the base is abstract
|
||||
(i.e. has at least one virtual function). The library uses the
|
||||
type trait macro <code style="white-space: normal">BOOST_IS_ABSTRACT(T)</code>
|
||||
to do this. Not all compilers support this type trait and corresponding
|
||||
@@ -333,10 +333,9 @@ This is illustrated by the test program
|
||||
Other implementations are possible and might be necessary for
|
||||
certain special cases.
|
||||
|
||||
version.hpp</a>.
|
||||
<h3><a name="wrappers">Wrappers</a></h3>
|
||||
Archives need to treat wrappers diffently from other types since, for example,
|
||||
they usually are non-const object while output archives require that any
|
||||
Archives need to treat wrappers differently from other types since, for example,
|
||||
they usually are non-const objects while output archives require that any
|
||||
serialized object (with the exception of a wrapper) be const.
|
||||
|
||||
This header file <a href="../../../boost/serialization/wrapper.hpp">wrapper.hpp</a>
|
||||
@@ -471,7 +470,7 @@ struct tracking_level<nvp<T> >
|
||||
#endif
|
||||
</code></pre>
|
||||
This can be problematic when one wants to make his code <strong>and archives</strong>
|
||||
portable to other platforms. It means the she objects will be serialized differently
|
||||
portable to other platforms. It means the objects will be serialized differently
|
||||
depending on the platform used. This implies that objects saved from one platform
|
||||
won't be loaded properly on another. In other words, archives won't be portable.
|
||||
<p>
|
||||
@@ -517,13 +516,13 @@ and template parameters should be assigned according to the following table:
|
||||
Some serialization traits can conflict with other ones. Sometimes these conflicts
|
||||
will result in erroneous behavior (E.G. creating of archives which could not be read)
|
||||
and other times they represent a probable misconception on the part of the
|
||||
library user which could result in suprising behavior. The extent possible,
|
||||
library user which could result in suprising behavior. To the extent possible,
|
||||
these conflicts are detected at compile time and errors (BOOST_STATIC_ASSERT)
|
||||
or warnings (BOOST_STATIC_WARNING) are generated. The are generated in a
|
||||
compiler dependent way manner which should show an chain of instantiation
|
||||
or warnings (BOOST_STATIC_WARNING) are generated. They are generated in a
|
||||
compiler dependent manner which should show a chain of instantiation
|
||||
to the point where the error/warning is detected. Without this capability,
|
||||
it would be very hard to track down errors or unexpected behavior in library
|
||||
usage. Here is list of the conflicts trapped:
|
||||
usage. Here is a list of the conflicts trapped:
|
||||
|
||||
<dl>
|
||||
<dt><h2><a name="object_level">object_level</a> - error</h2></dt>
|
||||
@@ -632,9 +631,9 @@ class K {
|
||||
discovered that when loading the archives made in the last month (reading the
|
||||
log). Things don't work. The second log entry is always the same as the
|
||||
first. After a series of very long and increasingly acrimonius email exchanges,
|
||||
its discovered
|
||||
that programmer (3) accidently broke programmer(2)'s code .This is because by
|
||||
serializing via a pointer, the "log" object now being tracked. This is because
|
||||
it's discovered
|
||||
that programmer(3) accidently broke programmer(2)'s code .This is because by
|
||||
serializing via a pointer, the "log" object is now being tracked. This is because
|
||||
the default tracking behavior is "track_selectively". This means that class
|
||||
instances are tracked only if they are serialized through pointers anywhere in
|
||||
the program. Now multiple saves from the same address result in only the first one
|
||||
@@ -642,11 +641,11 @@ its discovered
|
||||
data might have been changed. When it comes time to load the data, all instances of the log record show the same data.
|
||||
In this way, the behavior of a functioning piece of code is changed due the side
|
||||
effect of a change in an otherwise disjoint module.
|
||||
Worse yet, the data has been lost and cannot not be now recovered from the archives.
|
||||
Worse yet, the data has been lost and cannot be recovered from the archives.
|
||||
People are really upset and disappointed with boost (at least the serialization system).
|
||||
<p>
|
||||
<li>
|
||||
After a lot of investigation, it's discovered what the source of the problem
|
||||
After a lot of investigation, it's discovered what the source of the problem is
|
||||
and class construct_from is marked "track_never" by including:
|
||||
<code style="white-space: normal"><pre>
|
||||
BOOST_CLASS_TRACKING(construct_from, track_never)
|
||||
@@ -660,7 +659,7 @@ have its own distinct raw pointer. This will break
|
||||
<code style="white-space: normal">shared_ptr</code> and cause a memory leak. Again,
|
||||
The cause of this problem is very far removed from the point of discovery. It could
|
||||
well be that the problem is not even discovered until after the archives are loaded.
|
||||
Now we not only have difficult to find and fix program bug, but we have a bunch of
|
||||
Now we not only have a difficult to find and fix program bug, but we have a bunch of
|
||||
invalid archives and lost data.
|
||||
</ol>
|
||||
|
||||
@@ -673,7 +672,7 @@ invalid archives and lost data.
|
||||
ar << x;
|
||||
</pre></code>
|
||||
<p>
|
||||
<li>The programmer curses (another %^&*&* hoop to jump through). If he's in a
|
||||
<li>The programmer curses (another %^&*&* hoop to jump through). He's in a
|
||||
hurry (and who isn't) and would prefer not to <code style="white-space: normal">const_cast</code>
|
||||
- because it looks bad. So he'll just make the following change an move on.
|
||||
<code style="white-space: normal"><pre>
|
||||
@@ -697,8 +696,8 @@ ar << x
|
||||
<p>
|
||||
He's mildly annoyed now he tries the following:
|
||||
<ul>
|
||||
<li>He considers making f() a const - but presumable that shifts the const
|
||||
error to somewhere else. And his doesn't want to fiddle with "his" code to
|
||||
<li>He considers making f() a const - but presumably that shifts the const
|
||||
error to somewhere else. And he doesn't want to fiddle with "his" code to
|
||||
work around a quirk in the serializaition system
|
||||
<p>
|
||||
<li>He removes the <code style="white-space: normal">const</code>
|
||||
@@ -748,7 +747,7 @@ Note that in this second scenario
|
||||
|
||||
It's true that these messages may sometimes flag code that is currently correct and
|
||||
that this may be annoying to some programmers. However, this example illustrates
|
||||
my view that these messages are useful and that any such annoyance is small price to
|
||||
my view that these messages are useful and that any such annoyance is a small price to
|
||||
pay to avoid particularly vexing programming errors.
|
||||
|
||||
</dd>
|
||||
@@ -765,7 +764,7 @@ level <= object_serializable.
|
||||
in this case, indication that an object is tracked is
|
||||
not stored in the archive itself - see level == object_serializable.
|
||||
Since class information is not saved in the archive, the existence
|
||||
or absense of the operation ar << T * anywhere else in the
|
||||
or absence of the operation ar << T * anywhere else in the
|
||||
program is used to infer that an object of this type should be tracked.
|
||||
<p>
|
||||
A problem arises when a program which reads an archive
|
||||
|
||||
@@ -569,7 +569,7 @@ anywhere in the program - a memory leak.
|
||||
There are couple of ways of fixing this. One way is to explicitly manage the bus stops.
|
||||
However, a more robust and transparent is to use
|
||||
<code style="white-space: normal">shared_ptr</code> rather than raw pointers. Along
|
||||
with serialization implemenations for the Standard Library, the serialization library
|
||||
with serialization implementations for the Standard Library, the serialization library
|
||||
includes implementation of serialization for
|
||||
<code style="white-space: normal">boost::shared ptr</code>. Given this, it should be
|
||||
easy to alter any of these examples to eliminate the memory leak. This is left
|
||||
|
||||
@@ -29,7 +29,7 @@ http://www.boost.org/LICENSE_1_0.txt)
|
||||
C++ includes the operator <code style="white-space: normal">dynamic_cast<T>(U * u)</code>
|
||||
for casting a pointer at runtime between two related types. However, this can only be
|
||||
used for polymorphic classes. That is, it can only be used with related classes which have at least one virtual function.
|
||||
Limiting the serializaton of pointers to only such class would diminish the applicability
|
||||
Limiting the serializaton of pointers to only such classes would diminish the applicability
|
||||
of the library.
|
||||
|
||||
<h3>Usage</h3>
|
||||
|
||||
@@ -43,7 +43,7 @@ the <A href="traits.html#wrappers"><code>is_wrapper</code></a> trait for
|
||||
these wrapper classes is set to true.
|
||||
|
||||
<h3><a name="binaryobjects">Binary Objects</a></h3>
|
||||
A binary object is just an sequence of bytes stored as raw
|
||||
A binary object is just a sequence of bytes stored as raw
|
||||
binary data. This would most likely be used for a large amount
|
||||
of "light weight" data such as a pixel map or embedded binary file.
|
||||
The header file
|
||||
@@ -59,7 +59,7 @@ which will construct a temporary binary object that can be serialized just like
|
||||
Its default serialization is to use archive class primitives
|
||||
<code style="white-space: normal">save_binary</code> and <code>load_binary</code>.
|
||||
Note that it doesn't allocated any storage or create any objects.
|
||||
Its sole purpose is to pass the data size and address as pair to the archive class.
|
||||
Its sole purpose is to pass the data size and address as a pair to the archive class.
|
||||
|
||||
|
||||
<h3><a name="arrays">Arrays</a></h3>
|
||||
@@ -91,7 +91,7 @@ public:
|
||||
};
|
||||
</code></pre>
|
||||
that can be serialized just like any other object.
|
||||
Its default serialization is to use serialize each array element.
|
||||
Its default serialization is to serialize each array element.
|
||||
Note that it doesn't allocated any storage or create any objects.
|
||||
Its sole purpose is to pass the data type, size and address to the archive class.
|
||||
|
||||
@@ -171,7 +171,7 @@ xml_oarchive & operator&(const boost::serialization::nvp<T> & t)
|
||||
}
|
||||
</code></pre>
|
||||
The most obvious and convient name to assign to as the XML data item name
|
||||
is - surpise! - the name of the C++ class data member. So our serialization
|
||||
is - surprise! - the name of the C++ class data member. So our serialization
|
||||
code will look like:
|
||||
<pre><code>
|
||||
ar & make_nvp("my_variable", my_variable);
|
||||
|
||||
@@ -49,7 +49,7 @@ public:
|
||||
typedef enum {
|
||||
no_exception, // initialized without code
|
||||
other_exception, // any excepton not listed below
|
||||
unregistered_class, // attempt to serialize a pointer of an
|
||||
unregistered_class, // attempt to serialize a pointer of
|
||||
// an unregistered class
|
||||
invalid_signature, // first line of archive does not contain
|
||||
// expected string
|
||||
@@ -57,8 +57,8 @@ public:
|
||||
// subsequent to this one
|
||||
pointer_conflict, // an attempt has been made to directly
|
||||
// serialize an object which has
|
||||
// already been serialzed through a pointer.
|
||||
// Were this permited, the archive load would result
|
||||
// already been serialized through a pointer.
|
||||
// Were this permitted, the archive load would result
|
||||
// in the creation of an extra copy of the obect.
|
||||
incompatible_native_format, // attempt to read native binary format
|
||||
// on incompatible platform
|
||||
@@ -70,7 +70,7 @@ public:
|
||||
unregistered_cast, // base - derived relationship not registered with
|
||||
// void_cast_register
|
||||
unsupported_class_version, // type saved with a version # greater than the
|
||||
// one used by the program. This indicates that the proggram
|
||||
// one used by the program. This indicates that the program
|
||||
// needs to be rebuilt.
|
||||
multiple_code_instantiation, // code for implementing serialization for some
|
||||
// type has been instantiated in more than one module.
|
||||
|
||||
Reference in New Issue
Block a user