Merge pull request #1 from insideoutclub/develop

Develop
This commit is contained in:
Robert Ramey
2014-06-12 18:04:11 -07:00
30 changed files with 229 additions and 232 deletions

View File

@@ -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.

View File

@@ -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&lt;class T&gt;
void save(T &amp; 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 "&lt;name " before data.
by XML archive to inject "&lt;name&gt;" before data.
</dd>
<p>
@@ -161,12 +161,12 @@ by XML archive to inject "&lt;/name&gt;" 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 "&gt;" character at end of XML header. XML output archives
to determine when to inject a "&gt;" 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 "&gt;" 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 &lt;name ... &gt;...&lt;/name&gt; 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>&copy; Copyright <a href="http://www.rrsd.com">Robert Ramey</a> 2002-2004.

View File

@@ -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>

View File

@@ -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>&copy; Copyright <a href="http://www.rrsd.com">Robert Ramey</a> 2002-2004.

View File

@@ -42,7 +42,7 @@ template&lt;
<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&lt;
<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>

View File

@@ -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&lt; // insert line breaks every 76 characters
base64_from_binary&lt; // convert binary values ot base64 characters
base64_from_binary&lt; // convert binary values to base64 characters
transform_width&lt; // 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 =&gt; 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>

View File

@@ -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&lt;log_archive&gt;
{

View File

@@ -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

View File

@@ -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>

View File

@@ -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>

View File

@@ -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>

View File

@@ -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

View File

@@ -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>

View File

@@ -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

View File

@@ -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

View File

@@ -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

View File

@@ -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&nbsp;data
directly into/from &nbsp;the stream .&nbsp; This could
create a corrupted archive. Were archives

View File

@@ -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&lt; boost::shared_ptr&lt; my_t&gt; &gt;</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">&amp;</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">&gt;&gt;</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 &lt;list&gt;
</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

View File

@@ -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&lt;P, D&gt;</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&lt;
boost::detail::sp_counted_base,
&gt;();
</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>

View File

@@ -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">

View File

@@ -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&lt;T&gt;
</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&lt;T&gt;
</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&lt;T&gt;::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.

View File

@@ -33,9 +33,9 @@ operators:
<dt><code>static_cast&lt;T *<&gt;(U *)<br>static_cast&lt;T &<&gt;(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&lt;class T&gt;
bool is_storable(T &amp;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&lt;base1 &amp;&gt;(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&lt;base1 &amp;&gt;(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&lt;base1 &amp;&gt;(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&lt;Target &amp; &gt(Source &amp; 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&lt;Target &amp;&gt(Source &amp; 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(&lt;type&gt;)</code>
has been applied.

View File

@@ -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&lt;class Archive&gt;
@@ -112,7 +112,7 @@ void load(boost::basic_oarchive &amp; 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">&lt;boost/cstdint.hpp&gt;</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.

View File

@@ -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.

View File

@@ -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

View File

@@ -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&lt;nvp&lt;T&gt; &gt;
#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 &lt;&lt; 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 &lt;&lt; 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

View File

@@ -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

View File

@@ -29,7 +29,7 @@ http://www.boost.org/LICENSE_1_0.txt)
C++ includes the operator <code style="white-space: normal">dynamic_cast&lt;T&gt;(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>

View File

@@ -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);

View File

@@ -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.