Our archives have been factored in to a tree of classes in order to minimize repetition of code. This is shown in the accompanying class diagram. -All input archives should be derived from the following template: + +Any class which fullfills the following requirements will function as +a loading archive. + + +
template<class Archive>
detail::common_iarchive;
-void load(T &t);void load_binary(void *address, std::size_t size);stream as a template parameter rather than simple classes.
+ stream or
+ streambuf
+ as a template parameter rather than simple classes.
Combined with the above, even more issues arise with non-conforming compilers.
The attached class diagram
@@ -241,17 +253,15 @@ EXCEPT for one special case.
BOOT_CLASS_EXPORT is used to instantiate the serialization
- code for the included archives.
+ is, the macro BOOT_CLASS_EXPORT is used
+ to instantiate the serialization code for the included archives.
-#define BOOST_ARCHIVE_CUSTOM_OARCHIVE_TYPES trivial_oarchive
-#define BOOST_ARCHIVE_CUSTOM_IARCHIVE_TYPES trivial_iarchive
+#define BOOST_SERIALIZATION_REGISTER_ARCHIVE(Archive)
-before BOOST_CLASS_EXPORT is invoked for any serializable class.
Failure to do this will not inhibit the program from compiling, linking
and executing properly - except in one case. If an instance of a derived
class is serialized through a pointer to its base class, the program
@@ -259,8 +269,7 @@ will throw an
unregistered_class
exception.
-Only one of the above statements is permitted, However, any number of new archive -classes can be specified as list separated by commas. +
portable_binary_archive.hpp
+To test a new archive, for example, portable binary archives, with the gcc compiler,
+make a header file portable_binary_archive.hpp
and invoke bjam with
-sBOOST_ARCHIVE_LIST=portable_binary_archive.hpp
-This process in encapsulated in the shell script
-run_archive_test whose command line is
+This process in encapsulated in the shell or cmd script
+library_test whose command line is
-run_archive_test <test header file> <toolset> [<boost root>] [<target directory>]
+library_test --toolset=gcc -sBOOST_ARCHIVE_LIST=portable_binary_archive.hpp
polymorphic_iarchive_dispatch.hpp
+polymorphic_iarchive_route.hpp
and
-polymorphic_oarchive_dispatch.hpp.
+polymorphic_oarchive_route.hpp.
As these contain no code specific to the particular implementation archive, they can be used to create
a polymorphic archive implementation from any functioning templated archive implementation.
diff --git a/doc/archives.html b/doc/archives.html index 6444023d..7ac2886a 100644 --- a/doc/archives.html +++ b/doc/archives.html @@ -41,14 +41,14 @@ In the following descriptions
When an object is loaded to a temporary variable and later moved to another location, - This function must be called in order communicate this fact. This is permits the - the archive to properly implement object tracking. Object tracking is required in order + this function must be called in order communicate this fact. This permits the + archive to properly implement object tracking. Object tracking is required in order to correctly implement serialization of pointers to instances of derived classes.
@@ -215,7 +215,7 @@ archives is discussed in
The existence of the <<
-and >> suggest
+and >> suggests
a relationship between archives and C++ i/o streams. Archives are not
C++ i/o streams. All the archives included with this system take a stream
as an argument in the constructor and that stream is used for output or input.
@@ -224,7 +224,7 @@ archive interface. It just turns out that the archives written so far have
found it useful to base their implementation on streams.
Archive Models
-This library includes a various implementation of the Archive concept.
+This library includes various implementations of the Archive concept.
An archive is defined by two complementary classes. One is for saving data while
the other is for loading it.
@@ -307,7 +307,7 @@ public:
text_oarchive(std::ostream & os, unsigned int flags = 0);
stream as
+Constructs an archive given an open stream as
an argument and optional flags. For most applications there will be no need to use flags.
Flags are defined by enum archive_flags enumerator.
Multiple flags can be combined with the | operator.
@@ -339,7 +339,7 @@ tags, use no_xml_tag_checking flag.
xml_w?archive) renders it output as UTF-8 which can
+version (xml_w?archive) renders its output as UTF-8 which can
handle any wide character without loss of information.
std::string data is converted from multi-byte format to wide
character format using the current
diff --git a/doc/class_diagram.html b/doc/class_diagram.html
index e6a5f9a5..8d652879 100644
--- a/doc/class_diagram.html
+++ b/doc/class_diagram.html
@@ -52,14 +52,14 @@ common_iarchive<text_iarchive> text_iarchive_impl<text_iarchive> -> polymorphic_iarchive ->
+text_iarchive_impl<text_iarchive> -> polymorphic_iarchive_impl ->
| \ |
| \ |
- | \_____________________________________ |
+ | \_____________________________________ polymorphic_iarchive ->
| \ /
| \ /
| \ /
-text_iarchive -> polymorphic_iarchive_dispatch<text_iarchive_impl<text_iarchive> > ->
+text_iarchive -> polymorphic_iarchive_route<text_iarchive_impl<text_iarchive> > ->
|
|
|
@@ -68,7 +68,7 @@ common_iarchive<text_iarchive> blue
implement loading for a given archive type. (in this case its text archives).
Users include classes in red to load their data from a partcular
@@ -146,11 +146,11 @@ never change. They are in namespace boost::archive::detail
for all archives present and future.
- polymorphic_iarchive_dispatch<text_iarchive_impl<text_iarchive> >
+ polymorphic_iarchive_route<text_iarchive_impl<text_iarchive> >
This class implements the polymorphic_iarchive in terms of a specific
- concrete class. Virtual function calls are forwarded to the implementing class. In this example,
+ concrete class. Virtual function calls are routed to the implementing class. In this example,
that implementing class would be text_iarchive_impl.
@@ -158,7 +158,7 @@ never change. They are in namespace boost::archive::detail
this is just a typedef so we can write polymorphic_text_archive rather than
- polymorphic_iarchive_dispatch<text_iarchive_impl<text_iarchive> >
+ polymorphic_iarchive_route<text_iarchive_impl<text_iarchive> >
diff --git a/doc/codecvt.html b/doc/codecvt.html
index 5ff6c2df..85e9e797 100644
--- a/doc/codecvt.html
+++ b/doc/codecvt.html
@@ -28,7 +28,7 @@ width="277" height="86">
-UTF-8 Codecvt Facet
+utf8_codecvt_facet
diff --git a/doc/contents.html b/doc/contents.html
index a6ea530a..7c5b22d5 100644
--- a/doc/contents.html
+++ b/doc/contents.html
@@ -1,4 +1,4 @@
-
+
+
+
+
+
+Serialization - Proposed Case Studies
+
+
+
+
+
+ 
+
+
+ Serialization
+ Proposed Case Studies
+
+
+
+
+
+
+These are not part of the library itself, but rather
+techiques on how to use the library to address specific situations.
+
+Serializing a Function Object
+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
+this should be easily implementable.
+
+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
+encapsulates code.
+
+This case study would show how to do this.
+
+
Archive Adaptors
+
+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,
+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.
+For example, an adaptor for generating an xml schema could be
+appended to both wide narrow character versions of xml archives.
+
+This case study would show how to make a useful archive adaptor.
+
+
Archive Helpers
+Some types are not serializable as they stand. That is - they
+do not fullfill 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
+of unpaid employment for the library author. Rather than
+adding a bunch of special code to the library itself, this
+code can packaged as a "helper" or "mix-in" class. Then
+a new archive is derived from both the "base" archive class
+AND the "helper" class. This is how boost::shared_ptr
+has been implemented.
+
+It would also be possible to make a "generic runtime helper"
+which would effectively extend the API of the library. Previously
+the library included such a helper class. It was removed
+in favor of the current implementation. But this functionality
+should be added back in with another adaptor which would
+become part of the library.
+
+
+Revised 1 November, 2008
+
© Copyright Robert Ramey 2002-2008.
+Distributed under the Boost Software License, Version 1.0. (See
+accompanying file LICENSE_1_0.txt or copy at http://www.boost.org/LICENSE_1_0.txt)
+
+
+
diff --git a/doc/performance_status.html b/doc/performance_status.html
new file mode 100644
index 00000000..6ac4196f
--- /dev/null
+++ b/doc/performance_status.html
@@ -0,0 +1,30 @@
+
+
+Boost Library Status Automatic Test
+
+
+
+
+
+
+Library Status: serialization
+Run Date: 02:42:48 UTC, Tuesday 10 June 2008
+
+
+
+
+
+Test Name
+gcc-3.4.4
+
+profile
+ peformance_array_binary_archive Pass Profile
+peformance_array_text_archive Pass Profile
+peformance_array_text_warchive Missing
+peformance_array_xml_archive Pass Profile
+peformance_array_xml_warchive Missing
+performance_iterators Pass Profile
+performance_iterators_base64 Pass Profile
+
+
+
diff --git a/doc/profile1.txt b/doc/profile1.txt
new file mode 100644
index 00000000..db95c841
--- /dev/null
+++ b/doc/profile1.txt
@@ -0,0 +1,149 @@
+Flat profile:
+
+Each sample counts as 0.01 seconds.
+ no time accumulated
+
+ % cumulative self self total
+ time seconds seconds calls Ts/call Ts/call name
+ 0.00 0.00 0.00 200 0.00 0.00 void accumulate(unsigned int&, unsigned long const&)
+ 0.00 0.00 0.00 150 0.00 0.00 _pei386_runtime_relocator
+ 0.00 0.00 0.00 1 0.00 0.00 std::ostream::operator<<(void const*)
+ 0.00 0.00 0.00 1 0.00 0.00 __divdi3
+
+ % the percentage of the total running time of the
+time program used by this function.
+
+cumulative a running sum of the number of seconds accounted
+ seconds for by this function and those listed above it.
+
+ self the number of seconds accounted for by this
+seconds function alone. This is the major sort for this
+ listing.
+
+calls the number of times this function was invoked, if
+ this function is profiled, else blank.
+
+ self the average number of milliseconds spent in this
+ms/call function per call, if this function is profiled,
+ else blank.
+
+ total the average number of milliseconds spent in this
+ms/call function and its descendents per call, if this
+ function is profiled, else blank.
+
+name the name of the function. This is the minor sort
+ for this listing. The index shows the location of
+ the function in the gprof listing. If the index is
+ in parenthesis it shows where it would appear in
+ the gprof listing if it were to be printed.
+
+ Call graph (explanation follows)
+
+
+granularity: each sample hit covers 4 byte(s) no time propagated
+
+index % time self children called name
+ 0.00 0.00 200/200 setvbuf [1286]
+[4] 0.0 0.00 0.00 200 void accumulate(unsigned int&, unsigned long const&) [4]
+-----------------------------------------------
+ 0.00 0.00 150/150 _cygwin_crt0_common@8 [1230]
+[5] 0.0 0.00 0.00 150 _pei386_runtime_relocator [5]
+-----------------------------------------------
+ 0.00 0.00 1/1 _lseek64 [1234]
+[6] 0.0 0.00 0.00 1 std::ostream::operator<<(void const*) [6]
+-----------------------------------------------
+ 0.00 0.00 1/1 __tcf_1 [1221]
+[7] 0.0 0.00 0.00 1 __divdi3 [7]
+-----------------------------------------------
+ 2 main [1263]
+[1263] 0.0 0.00 0.00 0+2 main [1263]
+ 2 main [1263]
+-----------------------------------------------
+
+ This table describes the call tree of the program, and was sorted by
+ the total amount of time spent in each function and its children.
+
+ Each entry in this table consists of several lines. The line with the
+ index number at the left hand margin lists the current function.
+ The lines above it list the functions that called this function,
+ and the lines below it list the functions this one called.
+ This line lists:
+ index A unique number given to each element of the table.
+ Index numbers are sorted numerically.
+ The index number is printed next to every function name so
+ it is easier to look up where the function in the table.
+
+ % time This is the percentage of the `total' time that was spent
+ in this function and its children. Note that due to
+ different viewpoints, functions excluded by options, etc,
+ these numbers will NOT add up to 100%.
+
+ self This is the total amount of time spent in this function.
+
+ children This is the total amount of time propagated into this
+ function by its children.
+
+ called This is the number of times the function was called.
+ If the function called itself recursively, the number
+ only includes non-recursive calls, and is followed by
+ a `+' and the number of recursive calls.
+
+ name The name of the current function. The index number is
+ printed after it. If the function is a member of a
+ cycle, the cycle number is printed between the
+ function's name and the index number.
+
+
+ For the function's parents, the fields have the following meanings:
+
+ self This is the amount of time that was propagated directly
+ from the function into this parent.
+
+ children This is the amount of time that was propagated from
+ the function's children into this parent.
+
+ called This is the number of times this parent called the
+ function `/' the total number of times the function
+ was called. Recursive calls to the function are not
+ included in the number after the `/'.
+
+ name This is the name of the parent. The parent's index
+ number is printed after it. If the parent is a
+ member of a cycle, the cycle number is printed between
+ the name and the index number.
+
+ If the parents of the function cannot be determined, the word
+ `' is printed in the `name' field, and all the other
+ fields are blank.
+
+ For the function's children, the fields have the following meanings:
+
+ self This is the amount of time that was propagated directly
+ from the child into the function.
+
+ children This is the amount of time that was propagated from the
+ child's children to the function.
+
+ called This is the number of times the function called
+ this child `/' the total number of times the child
+ was called. Recursive calls by the child are not
+ listed in the number after the `/'.
+
+ name This is the name of the child. The child's index
+ number is printed after it. If the child is a
+ member of a cycle, the cycle number is printed
+ between the name and the index number.
+
+ If there are any cycles (circles) in the call graph, there is an
+ entry for the cycle-as-a-whole. This entry shows who called the
+ cycle (as parents) and the members of the cycle (as children.)
+ The `+' recursive calls entry shows the number of function calls that
+ were internal to the cycle, and the calls entry for each member shows,
+ for that member, how many times it was called from other members of
+ the cycle.
+
+
+Index by function name
+
+ [4] void accumulate(unsigned int&, unsigned long const&) [7] __divdi3
+ [6] std::ostream::operator<<(void const*) [5] _pei386_runtime_relocator
diff --git a/doc/profile2.txt b/doc/profile2.txt
new file mode 100644
index 00000000..a2cac6d2
--- /dev/null
+++ b/doc/profile2.txt
@@ -0,0 +1,203 @@
+Flat profile:
+
+Each sample counts as 0.01 seconds.
+ % cumulative self self total
+ time seconds seconds calls Ts/call Ts/call name
+100.00 0.01 0.01 __gnu_cxx::__atomic_add(int volatile*, int)
+ 0.00 0.01 0.00 51 0.00 0.00 boost::archive::iterators::transform_width::fill()
+ 0.00 0.01 0.00 36 0.00 0.00 boost::archive::iterators::transform_width<__gnu_cxx::__normal_iterator > >, 8, 6, char>::fill()
+ 0.00 0.01 0.00 30 0.00 0.00 std::vector >::_M_insert_aux(__gnu_cxx::__normal_iterator > >, char const&)
+ 0.00 0.01 0.00 11 0.00 0.00 boost::archive::iterators::xml_escape::fill(char const*&, char const*&)
+ 0.00 0.01 0.00 9 0.00 0.00 void test_transform_width<6, 8>(unsigned int)
+ 0.00 0.01 0.00 9 0.00 0.00 boost::archive::iterators::xml_unescape::drain()
+ 0.00 0.01 0.00 5 0.00 0.00 boost::archive::iterators::xml_unescape::drain_residue(char const*)
+ 0.00 0.01 0.00 2 0.00 0.00 __static_initialization_and_destruction_0(int, int)
+ 0.00 0.01 0.00 1 0.00 0.00 void test_xml_escape(char const*, char const*, unsigned int)
+ 0.00 0.01 0.00 1 0.00 0.00 void test_xml_unescape(char const*, char const*, unsigned int)
+ 0.00 0.01 0.00 1 0.00 0.00 void test_stream_iterators(char const*, unsigned int)
+ 0.00 0.01 0.00 1 0.00 0.00 test_main(int, char**)
+ 0.00 0.01 0.00 1 0.00 0.00 char* std::string::_S_construct(char*, char*, std::allocator const&, std::forward_iterator_tag)
+ 0.00 0.01 0.00 1 0.00 0.00 std::basic_string, std::allocator >::basic_string(char*, char*, std::allocator const&)
+
+ % the percentage of the total running time of the
+time program used by this function.
+
+cumulative a running sum of the number of seconds accounted
+ seconds for by this function and those listed above it.
+
+ self the number of seconds accounted for by this
+seconds function alone. This is the major sort for this
+ listing.
+
+calls the number of times this function was invoked, if
+ this function is profiled, else blank.
+
+ self the average number of milliseconds spent in this
+ms/call function per call, if this function is profiled,
+ else blank.
+
+ total the average number of milliseconds spent in this
+ms/call function and its descendents per call, if this
+ function is profiled, else blank.
+
+name the name of the function. This is the minor sort
+ for this listing. The index shows the location of
+ the function in the gprof listing. If the index is
+ in parenthesis it shows where it would appear in
+ the gprof listing if it were to be printed.
+
+ Call graph (explanation follows)
+
+
+granularity: each sample hit covers 4 byte(s) for 100.00% of 0.01 seconds
+
+index % time self children called name
+
+[1] 100.0 0.01 0.00 __gnu_cxx::__atomic_add(int volatile*, int) [1]
+-----------------------------------------------
+ 0.00 0.00 51/51 void test_transform_width<6, 8>(unsigned int) [9]
+[5] 0.0 0.00 0.00 51 boost::archive::iterators::transform_width::fill() [5]
+-----------------------------------------------
+ 0.00 0.00 36/36 void test_transform_width<6, 8>(unsigned int) [9]
+[6] 0.0 0.00 0.00 36 boost::archive::iterators::transform_width<__gnu_cxx::__normal_iterator > >, 8, 6, char>::fill() [6]
+-----------------------------------------------
+ 0.00 0.00 30/30 void test_transform_width<6, 8>(unsigned int) [9]
+[7] 0.0 0.00 0.00 30 std::vector >::_M_insert_aux(__gnu_cxx::__normal_iterator > >, char const&) [7]
+-----------------------------------------------
+ 0.00 0.00 11/11 void test_xml_escape(char const*, char const*, unsigned int) [13]
+[8] 0.0 0.00 0.00 11 boost::archive::iterators::xml_escape::fill(char const*&, char const*&) [8]
+-----------------------------------------------
+ 0.00 0.00 9/9 test_main(int, char**) [16]
+[9] 0.0 0.00 0.00 9 void test_transform_width<6, 8>(unsigned int) [9]
+ 0.00 0.00 51/51 boost::archive::iterators::transform_width::fill() [5]
+ 0.00 0.00 36/36 boost::archive::iterators::transform_width<__gnu_cxx::__normal_iterator > >, 8, 6, char>::fill() [6]
+ 0.00 0.00 30/30 std::vector >::_M_insert_aux(__gnu_cxx::__normal_iterator > >, char const&) [7]
+-----------------------------------------------
+ 0.00 0.00 9/9 void test_xml_unescape(char const*, char const*, unsigned int) [14]
+[10] 0.0 0.00 0.00 9 boost::archive::iterators::xml_unescape::drain() [10]
+ 0.00 0.00 5/5 boost::archive::iterators::xml_unescape::drain_residue(char const*) [11]
+-----------------------------------------------
+ 0.00 0.00 5/5 boost::archive::iterators::xml_unescape::drain() [10]
+[11] 0.0 0.00 0.00 5 boost::archive::iterators::xml_unescape::drain_residue(char const*) [11]
+-----------------------------------------------
+ 0.00 0.00 1/2 global constructors keyed to main [38]
+ 0.00 0.00 1/2 global destructors keyed to main [35]
+[12] 0.0 0.00 0.00 2 __static_initialization_and_destruction_0(int, int) [12]
+-----------------------------------------------
+ 0.00 0.00 1/1 test_main(int, char**) [16]
+[13] 0.0 0.00 0.00 1 void test_xml_escape(char const*, char const*, unsigned int) [13]
+ 0.00 0.00 11/11 boost::archive::iterators::xml_escape::fill(char const*&, char const*&) [8]
+-----------------------------------------------
+ 0.00 0.00 1/1 test_main(int, char**) [16]
+[14] 0.0 0.00 0.00 1 void test_xml_unescape(char const*, char const*, unsigned int) [14]
+ 0.00 0.00 9/9 boost::archive::iterators::xml_unescape::drain() [10]
+-----------------------------------------------
+ 0.00 0.00 1/1 test_main(int, char**) [16]
+[15] 0.0 0.00 0.00 1 void test_stream_iterators(char const*, unsigned int) [15]
+ 0.00 0.00 1/1 std::basic_string, std::allocator >::basic_string(char*, char*, std::allocator const&) [18]
+-----------------------------------------------
+ 0.00 0.00 1/1 main [1211]
+[16] 0.0 0.00 0.00 1 test_main(int, char**) [16]
+ 0.00 0.00 9/9 void test_transform_width<6, 8>(unsigned int) [9]
+ 0.00 0.00 1/1 void test_xml_escape(char const*, char const*, unsigned int) [13]
+ 0.00 0.00 1/1 void test_xml_unescape(char const*, char const*, unsigned int) [14]
+ 0.00 0.00 1/1 void test_stream_iterators(char const*, unsigned int) [15]
+-----------------------------------------------
+ 0.00 0.00 1/1 std::basic_string, std::allocator >::basic_string(char*, char*, std::allocator const&) [18]
+[17] 0.0 0.00 0.00 1 char* std::string::_S_construct(char*, char*, std::allocator const&, std::forward_iterator_tag) [17]
+-----------------------------------------------
+ 0.00 0.00 1/1 void test_stream_iterators(char const*, unsigned int) [15]
+[18] 0.0 0.00 0.00 1 std::basic_string, std::allocator >::basic_string(char*, char*, std::allocator const&) [18]
+ 0.00 0.00 1/1 char* std::string::_S_construct(char*, char*, std::allocator const&, std::forward_iterator_tag) [17]
+-----------------------------------------------
+
+ This table describes the call tree of the program, and was sorted by
+ the total amount of time spent in each function and its children.
+
+ Each entry in this table consists of several lines. The line with the
+ index number at the left hand margin lists the current function.
+ The lines above it list the functions that called this function,
+ and the lines below it list the functions this one called.
+ This line lists:
+ index A unique number given to each element of the table.
+ Index numbers are sorted numerically.
+ The index number is printed next to every function name so
+ it is easier to look up where the function in the table.
+
+ % time This is the percentage of the `total' time that was spent
+ in this function and its children. Note that due to
+ different viewpoints, functions excluded by options, etc,
+ these numbers will NOT add up to 100%.
+
+ self This is the total amount of time spent in this function.
+
+ children This is the total amount of time propagated into this
+ function by its children.
+
+ called This is the number of times the function was called.
+ If the function called itself recursively, the number
+ only includes non-recursive calls, and is followed by
+ a `+' and the number of recursive calls.
+
+ name The name of the current function. The index number is
+ printed after it. If the function is a member of a
+ cycle, the cycle number is printed between the
+ function's name and the index number.
+
+
+ For the function's parents, the fields have the following meanings:
+
+ self This is the amount of time that was propagated directly
+ from the function into this parent.
+
+ children This is the amount of time that was propagated from
+ the function's children into this parent.
+
+ called This is the number of times this parent called the
+ function `/' the total number of times the function
+ was called. Recursive calls to the function are not
+ included in the number after the `/'.
+
+ name This is the name of the parent. The parent's index
+ number is printed after it. If the parent is a
+ member of a cycle, the cycle number is printed between
+ the name and the index number.
+
+ If the parents of the function cannot be determined, the word
+ `' is printed in the `name' field, and all the other
+ fields are blank.
+
+ For the function's children, the fields have the following meanings:
+
+ self This is the amount of time that was propagated directly
+ from the child into the function.
+
+ children This is the amount of time that was propagated from the
+ child's children to the function.
+
+ called This is the number of times the function called
+ this child `/' the total number of times the child
+ was called. Recursive calls by the child are not
+ listed in the number after the `/'.
+
+ name This is the name of the child. The child's index
+ number is printed after it. If the child is a
+ member of a cycle, the cycle number is printed
+ between the name and the index number.
+
+ If there are any cycles (circles) in the call graph, there is an
+ entry for the cycle-as-a-whole. This entry shows who called the
+ cycle (as parents) and the members of the cycle (as children.)
+ The `+' recursive calls entry shows the number of function calls that
+ were internal to the cycle, and the calls entry for each member shows,
+ for that member, how many times it was called from other members of
+ the cycle.
+
+
+Index by function name
+
+ [13] void test_xml_escape(char const*, char const*, unsigned int) [16] test_main(int, char**) [5] boost::archive::iterators::transform_width::fill()
+ [14] void test_xml_unescape(char const*, char const*, unsigned int) [8] boost::archive::iterators::xml_escape::fill(char const*&, char const*&) [1] __gnu_cxx::__atomic_add(int volatile*, int)
+ [9] void test_transform_width<6, 8>(unsigned int) [11] boost::archive::iterators::xml_unescape::drain_residue(char const*) [17] char* std::string::_S_construct(char*, char*, std::allocator const&, std::forward_iterator_tag)
+ [15] void test_stream_iterators(char const*, unsigned int) [10] boost::archive::iterators::xml_unescape::drain() [18] std::basic_string, std::allocator >::basic_string(char*, char*, std::allocator const&)
+ [12] __static_initialization_and_destruction_0(int, int) (performance_iterators.cpp) [6] boost::archive::iterators::transform_width<__gnu_cxx::__normal_iterator > >, 8, 6, char>::fill() [7] std::vector >::_M_insert_aux(__gnu_cxx::__normal_iterator > >, char const&)
diff --git a/doc/profile3.txt b/doc/profile3.txt
new file mode 100644
index 00000000..807e243c
--- /dev/null
+++ b/doc/profile3.txt
@@ -0,0 +1,153 @@
+Flat profile:
+
+Each sample counts as 0.01 seconds.
+ no time accumulated
+
+ % cumulative self self total
+ time seconds seconds calls Ts/call Ts/call name
+ 0.00 0.00 0.00 200 0.00 0.00 boost::archive::iterators::transform_width::fill()
+ 0.00 0.00 0.00 150 0.00 0.00 boost::archive::iterators::transform_width >, char>, 8, 6, char>::fill()
+ 0.00 0.00 0.00 2 0.00 0.00 __static_initialization_and_destruction_0(int, int)
+ 0.00 0.00 0.00 1 0.00 0.00 void test_base64()
+ 0.00 0.00 0.00 1 0.00 0.00 std::_List_base >::_M_clear()
+
+ % the percentage of the total running time of the
+time program used by this function.
+
+cumulative a running sum of the number of seconds accounted
+ seconds for by this function and those listed above it.
+
+ self the number of seconds accounted for by this
+seconds function alone. This is the major sort for this
+ listing.
+
+calls the number of times this function was invoked, if
+ this function is profiled, else blank.
+
+ self the average number of milliseconds spent in this
+ms/call function per call, if this function is profiled,
+ else blank.
+
+ total the average number of milliseconds spent in this
+ms/call function and its descendents per call, if this
+ function is profiled, else blank.
+
+name the name of the function. This is the minor sort
+ for this listing. The index shows the location of
+ the function in the gprof listing. If the index is
+ in parenthesis it shows where it would appear in
+ the gprof listing if it were to be printed.
+
+ Call graph (explanation follows)
+
+
+granularity: each sample hit covers 4 byte(s) no time propagated
+
+index % time self children called name
+ 0.00 0.00 200/200 void test_base64() [7]
+[4] 0.0 0.00 0.00 200 boost::archive::iterators::transform_width::fill() [4]
+-----------------------------------------------
+ 0.00 0.00 150/150 void test_base64() [7]
+[5] 0.0 0.00 0.00 150 boost::archive::iterators::transform_width >, char>, 8, 6, char>::fill() [5]
+-----------------------------------------------
+ 0.00 0.00 1/2 global constructors keyed to main [27]
+ 0.00 0.00 1/2 global destructors keyed to main [24]
+[6] 0.0 0.00 0.00 2 __static_initialization_and_destruction_0(int, int) [6]
+-----------------------------------------------
+ 0.00 0.00 1/1 main [1156]
+[7] 0.0 0.00 0.00 1 void test_base64() [7]
+ 0.00 0.00 200/200 boost::archive::iterators::transform_width::fill() [4]
+ 0.00 0.00 150/150 boost::archive::iterators::transform_width >, char>, 8, 6, char>::fill() [5]
+ 0.00 0.00 1/1 std::_List_base >::_M_clear() [8]
+-----------------------------------------------
+ 0.00 0.00 1/1 void test_base64() [7]
+[8] 0.0 0.00 0.00 1 std::_List_base >::_M_clear() [8]
+-----------------------------------------------
+
+ This table describes the call tree of the program, and was sorted by
+ the total amount of time spent in each function and its children.
+
+ Each entry in this table consists of several lines. The line with the
+ index number at the left hand margin lists the current function.
+ The lines above it list the functions that called this function,
+ and the lines below it list the functions this one called.
+ This line lists:
+ index A unique number given to each element of the table.
+ Index numbers are sorted numerically.
+ The index number is printed next to every function name so
+ it is easier to look up where the function in the table.
+
+ % time This is the percentage of the `total' time that was spent
+ in this function and its children. Note that due to
+ different viewpoints, functions excluded by options, etc,
+ these numbers will NOT add up to 100%.
+
+ self This is the total amount of time spent in this function.
+
+ children This is the total amount of time propagated into this
+ function by its children.
+
+ called This is the number of times the function was called.
+ If the function called itself recursively, the number
+ only includes non-recursive calls, and is followed by
+ a `+' and the number of recursive calls.
+
+ name The name of the current function. The index number is
+ printed after it. If the function is a member of a
+ cycle, the cycle number is printed between the
+ function's name and the index number.
+
+
+ For the function's parents, the fields have the following meanings:
+
+ self This is the amount of time that was propagated directly
+ from the function into this parent.
+
+ children This is the amount of time that was propagated from
+ the function's children into this parent.
+
+ called This is the number of times this parent called the
+ function `/' the total number of times the function
+ was called. Recursive calls to the function are not
+ included in the number after the `/'.
+
+ name This is the name of the parent. The parent's index
+ number is printed after it. If the parent is a
+ member of a cycle, the cycle number is printed between
+ the name and the index number.
+
+ If the parents of the function cannot be determined, the word
+ `' is printed in the `name' field, and all the other
+ fields are blank.
+
+ For the function's children, the fields have the following meanings:
+
+ self This is the amount of time that was propagated directly
+ from the child into the function.
+
+ children This is the amount of time that was propagated from the
+ child's children to the function.
+
+ called This is the number of times the function called
+ this child `/' the total number of times the child
+ was called. Recursive calls by the child are not
+ listed in the number after the `/'.
+
+ name This is the name of the child. The child's index
+ number is printed after it. If the child is a
+ member of a cycle, the cycle number is printed
+ between the name and the index number.
+
+ If there are any cycles (circles) in the call graph, there is an
+ entry for the cycle-as-a-whole. This entry shows who called the
+ cycle (as parents) and the members of the cycle (as children.)
+ The `+' recursive calls entry shows the number of function calls that
+ were internal to the cycle, and the calls entry for each member shows,
+ for that member, how many times it was called from other members of
+ the cycle.
+
+
+Index by function name
+
+ [7] void test_base64() [5] boost::archive::iterators::transform_width >, char>, 8, 6, char>::fill() [8] std::_List_base >::_M_clear()
+ [6] __static_initialization_and_destruction_0(int, int) (performance_iterators_base64.cpp) [4] boost::archive::iterators::transform_width::fill()
diff --git a/doc/rationale.html b/doc/rationale.html
index 3641bc03..c96fa139 100644
--- a/doc/rationale.html
+++ b/doc/rationale.html
@@ -228,7 +228,7 @@ its discovered
After a lot of investigation, it's discovered what the source of the problem
and class construct_from is marked "track_never" by including:
-BOOST_SERIALIZATION_TRACKING(construct_from, track_never)
+BOOST_CLASS_TRACKING(construct_from, track_never)
Now everything works again. Or - so it seems.
@@ -298,7 +298,7 @@ ar << x
might not even be written yet). OK, I'll add the following to my
construct_from.hpp to solve the problem.
-BOOST_SERIALIZATION_TRACKING(construct_from, track_never)
+BOOST_CLASS_TRACKING(construct_from, track_never)
@@ -311,7 +311,7 @@ BOOST_SERIALIZATION_TRACKING(construct_from, track_never)
But now he gets another trap - trying to save an object of a
class marked "track_never" through a pointer. So he goes back to
construct_from.hpp and comments out the
- BOOST_SERIALIZATION_TRACKING that
+ BOOST_CLASS_TRACKING that
was inserted. Now the second trap is avoided, But damn - the first trap is
popping up again. Eventually, after some code restructuring, the differing
requirements of serializating construct_from
diff --git a/doc/release.html b/doc/release.html
index 82dd3912..6036d846 100644
--- a/doc/release.html
+++ b/doc/release.html
@@ -1,4 +1,4 @@
-
+
+
+Differences from Boost 1.35
+
+ - The library is now thread safe. That is, multiple archives can be open
+ in different threads. This has been implmented with a lock-free algorithm
+ to avoid any performance bottlenecks.
+
- Serialization of types defined in shared libraries is now supported.
+ shared libraries (DLLS) can be loaded/unloaded dynamically at runtime.
+ This includes the serialization of instances of abstract base classes so that
+ a program can be written so as to be compatible with as yet undefined
+ and un-implemented code.
+
- The extended type info system has been enhanced to in order to implement
+ the above. It is now a general purpose system for creating and casting of
+ types about which is only known a string ID and an abstract base class.
+
- All bug reports filed as TRAK tickets have been addressed.
+
- As of this writing, the library will fail build on older compilers such
+ as MSVC before version 7.1 and older versions of Borland compilers. This
+ might or might not change in the future.
+
+
+Differences from Boost 1.34
+
+ - Enhanced support for fast serialization for native binary archives. By Mattias Troyer.
+
- Improved implementation of "export" functionality. Removes header ordering
+ requirement and eliminates the maintenance of a pre-determined list of "known archives"
+ By David Abrahams.
+
- Improved support for STLPort.
+
+
+Differences from Boost 1.33
+
+ - Native Binary archives use the
std::streambuf interface.
+ This should result in noticeably faster execution in many cases.
+
Differences from Boost 1.32
- Dynamic Linking Library (DLLs and shared libraries) for platforms which support them. See
- Automatic Linking on Windows.
+ Automatic Linking on Windows.
- Implementation of auto-link for compilers which can support this.
- Better support for Argument Dependent Lookup and two-phase lookup.
This results in simpler rules regarding the placing of serialization specializations
@@ -66,7 +103,7 @@ at the front of the list of include paths.
- Improved
const correctness for save/load operators. Note that this may
produce compile time errors in code which compiled without problem in earlier boost releases.
In most cases the fix is trivial. In other cases, code should be scrutinized to be
- sure that it doesn't use the serializaton system in a way which may introduce subtle bugs in
+ sure that it doesn't use the serialization system in a way which may introduce subtle bugs in
to the program. A fuller explanation of this issue can be found
here.
- A new implementation of serialization for
shared_ptr<T>. This
@@ -78,42 +115,24 @@ at the front of the list of include paths.
needs to load archives created with boost 1.32 libraries, include the above header
before each inclusion of boost/serialization/shared_ptr.hpp.
- More compilers tested and supported.
-
- Miscelleanous bug fixes.
-
-Differences from Boost 1.33
-
- - Native Binary archives use the
std::streambuf interface.
- This should result in noticibly faster execution in many cases.
-
-
-Differences from Boost 1.34
-
- - Ehanced support for fast serialiation for native binary archives. By Mattias Troyer.
-
- Improved implementation of "export" functionality. Removes header ordering
- requirement and eliminates the maintainence of a pre-determined list of "known archives"
- By David Abrahams.
-
- Improved support for STLPort.
+
- Miscellaneous bug fixes.
Pending issues
- - Compile, and test on more platforms
-
- implement
is_virtual_base<T> to automatically
- eliminate redundancy in virtual base class serialization.
- currently can't serialize through a pointer an object a of class
that implements its own
new/delete operators.
- Its possible that
std::string
and std::wstring contain characters such as
- '\0' which cannot be rendered in XML without an escape mechanism. Currently there is
- no such escape mechanism implemented.
- - A subtle error in the implementation of serialiaton of
std::map
+ '\0' and -1 (EOF) which cannot be rendered in text and XML archives without an escape mechanism.
+ Currently there is no such escape mechanism implemented.
+ - A subtle error in the implementation of serializaton of
std::map
is fixed in this version. Unfortunately, the fix breaks serialization of
std::map for those compilers which do not support
partial template specialization.
- - Floating point values which are number cannot be serialized to text base archives.
-
+
-Aside from the above, there are a number of issus related to specific platforms.
+Aside from the above, there are a number of issues related to specific platforms.
These are listed in Specific Compiler/Library Issues.
diff --git a/doc/serialization.html b/doc/serialization.html
index ec9826ae..f71e1842 100644
--- a/doc/serialization.html
+++ b/doc/serialization.html
@@ -48,12 +48,13 @@ http://www.boost.org/LICENSE_1_0.txt)
Free Functions
- Pointers
+ Pointers
- Non-Default Constructors
- Pointers to Objects of Derived Classes
- Registration
+
- Export
- Instantiation
- Selective Tracking
- Runtime Casting
@@ -77,14 +78,15 @@ if and only if one of the following is true:
serialization traits,
any user type can also be designated as "primitive"
so that it is handled in this way.
-
- It is a class type and one of the following has been declared:
+
- It is a class type and one of the following has been declared according
+ to the prototypes detailed below:
- a class member function
serialize
- a global function
serialize
- it is a pointer to a Serializable type.
- it is a reference to a Serializable type.
-
- it is an native C++ Array of Serializable type.
+
- it is a native C++ Array of Serializable type.
Primitive Types
@@ -675,8 +677,9 @@ main(){
Note that if the serialization function is split between save and load, both
functions must include the registration. This is required to keep the save
and corresponding load in syncronization.
-
-This will work but may be inconvenient. We don't always know which derived
+
+
Export
+The above will work but may be inconvenient. We don't always know which derived
classes we are going to serialize when we write the code to serialize through
a base class pointer. Every time a new derived class is written we have to
go back to all the places where the base class is serialized and update the
@@ -791,8 +794,8 @@ class derived : public base {
boost::serialization::base_object<base>(*this);
// method 2 : explicitly register base/derived relationship
boost::serialization::void_cast_register<derived, base>(
- static_cast<base *>(NULL),
- static_cast<derived *>(NULL)
+ static_cast<derived *>(NULL),
+ static_cast<base *>(NULL)
)
}
};
@@ -919,7 +922,7 @@ As of this writing, the library contains serialization of the following boost cl
- auto_ptr (demo)
Others are being added to the list so check the boost files section and headers for
-new implmentations!
+new implementations!
© Copyright Robert Ramey 2002-2004.
Distributed under the Boost Software License, Version 1.0. (See
diff --git a/doc/shared_ptr2.html b/doc/shared_ptr2.html
index 3c2ee360..0e831b79 100644
--- a/doc/shared_ptr2.html
+++ b/doc/shared_ptr2.html
@@ -20,7 +20,7 @@ http://www.boost.org/LICENSE_1_0.txt)
Serialization
- shared_ptr<class T> Revisted
+ shared_ptr<class T> Revisited
@@ -32,7 +32,7 @@ Unfortunately, this way of doing it suffered from some undesirable features
- It was dependent on the Boost implementation of
shared_ptr.
The shared_ptr interface has been included
in std::tr1 and may someday be included in the standard
- C++ library. An implementation which depends only on the public interface can be guarenteed to
+ C++ library. An implementation which depends only on the public interface can be guaranteed to
function with any other future implementation of shared_ptr.
- It required extra macros for export.
@@ -45,7 +45,7 @@ inline void save(
const unsigned int /* file_version */
){
const T * t_ptr = t.get();
- // just seriailize the underlying raw pointer
+ // just serialize the underlying raw pointer
ar <<: boost::serialization::make_nvp("px", t_ptr);
}
@@ -56,7 +56,7 @@ inline void load(
const unsigned int file_version
){
T* r;
- // recover the underlying raw poiter
+ // recover the underlying raw pointer
ar >> boost::serialization::make_nvp("px", r);
// To Do - match up with other shared pointers which
@@ -65,13 +65,13 @@ inline void load(
}
-In priniciple this is very much simpler than the original implementation. Completion of
+In principle, this is very much simpler than the original implementation. Completion of
this code requires:
shared_ptr instances.
- weak_ptr.
diff --git a/doc/singleton.html b/doc/singleton.html
new file mode 100644
index 00000000..737ccdde
--- /dev/null
+++ b/doc/singleton.html
@@ -0,0 +1,241 @@
+
+
+
+
+
+
+
+|
+ |
+
+ Serialization+
+ |
+
main is called
+ regardless of where they might be referenced within the program.
+ In a multi-tasking system, this guarentees that there will be no
+ race conditions during the construction of any instance. No
+ thread locking is required to guarentee this.
+ const
+ instances are thread-safe during the whole program. Again, no
+ thread locking is required.
+ main is called.
+ For a more general purpose usage, thread locking on this
+ singleton could easily be implemented. But as the serialization
+ library didn't require it, it wasn't implemented.
+
+namespace boost {
+namespace serialization {
+
+template
+class singleton : public boost::noncopyable
+{
+public:
+ static const T & get_const_instance();
+ static T & get_mutable_instance();
+};
+
+} // namespace serialization
+} // namespace boost
+
+
+
+static const T & get_const_instance();
+static T & get_mutable_instance();
+singleton<T>
+
+
+, 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
+
+
+singleton<T>
+
+
+and all accesss is through the above static interface
+functions, common member functions of T become
+the functional equivalent of
+static functions.
+
+
+The first way is illustrated by and excerpt from the file
+extended_type_info.cpp.
+which contains the following code:
+
+
+typedef std::set ktmap;
+...
+void
+extended_type_info::key_register(const char *key) {
+ ...
+ result = singleton::get_mutable_instance().insert(this);
+ ...
+}
+
+Just by referring to the singleton instance anywhere in the program
+will guarentee that one and only one instance for the specified
+type (ktmap in this example)
+will exist throughout the program. There is no need for anyother
+declaration or definition.
+
+A second way is to use
+
+
+singleton<T>
+
+
+as one of the base classes of the type. This is illustrated by a simplified
+excerpt from
+
+
+extended_type_info_typeid.hpp
+
+
+
+
+template<class T>
+class extended_type_info_typeid :
+ public detail::extended_type_info_typeid_0,
+ public singleton<extended_type_info_typeid<const T> >
+{
+ friend class singleton<extended_type_info_typeid<const T> >;
+private:
+ // private constructor to inhibit any existence other than the
+ // static one. Note: not all compilers support this !!!
+ extended_type_info_typeid() :
+ detail::extended_type_info_typeid_0()
+ {
+ type_register(typeid(T));
+ }
+ ~extended_type_info_typeid(){}
+ ...
+};
+
+
+This usage will permit a more natural syntax to be used:
+
+extended_type_info_typeid<T>::get_const_instance()
+
+
+Again, including one or more of the above statements anywhere
+in the program will guarentee that one and only one instance
+is created and referred to.
+
++Do not call get_mutable_instance when more than one thread is running! +
+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. +
+boost::serialization::global_lock::get_mutable_instance().lock();
+boost::serialization::global_lock::get_mutable_instance().unlock();
+
+In a program compiled for debug, any invocation of
+get_mutable_instance()
+while the library is in a "locked" state will trap in an assertion.
+The global_lock state is initialized as "unlocked" to permit
+alteration of static variables before
+main is called. All
+serialization tests invoke lock()
+at the start of the progam. For programs compiled in release
+mode these functions have no effect.
+
+© Copyright Robert Ramey 2007. +Distributed under the Boost Software License, Version 1.0. (See +accompanying file LICENSE_1_0.txt or copy at http://www.boost.org/LICENSE_1_0.txt) +
+ + diff --git a/doc/special.html b/doc/special.html index b2e0efed..440e08c8 100644 --- a/doc/special.html +++ b/doc/special.html @@ -27,7 +27,6 @@ http://www.boost.org/LICENSE_1_0.txt)BOOST_CLASS_EXPORT. This is used to make the serialization library aware
-that code should be instantiated for serialization of a given class even though the
-class hasn't been otherwise referred to by the program. This functionality
-is necessary to implement serialization of pointers through a virtual base
-class pointer. That is, a polymorphic pointer.
-
-This macro specifies a "Globally Unique IDentifier".
-This is an string which identifies the class to be created when data is loaded.
-Generally a text representation of the class name is sufficient for this purpose,
-but in certain cases it maybe necessary to specify a different string by using
-BOOST_CLASS_EXPORT_GUID
-rather than a simple
-BOOST_CLASS_EXPORT.
-
-
-BOOST_CLASS_EXPORT would usually
-be specified in the same header file as the class declaration to which it
-corresponds. That is, BOOST_CLASS_EXPORT(T)
-is a "trait" of the class T. So a program using this class will look
-something like:
-
-
-#include <boost/archive/xml_oarchive.hpp>
-.... // any other archive classes
-#include "my_class.hpp" // which contains BOOST_CLASS_EXPORT(my_class)
-
-
-These headers can be in any order. (In boost versions 1.34
-and earlier, the archive headers had to go before any headers which
-contain BOOST_CLASS_EXPORT.)
-Any code required to serialize types specified
-by BOOST_CLASS_EXPORT will be
-instantiated for each archive whose header is included. (note that the code
-is instantiated regardless of whether or not it is actually invoked.)
-If no archive headers are included - no code should be instantiated.
-This will permit BOOST_CLASS_EXPORT
-to be a permanent part of the my_class.hpp .
-
--Note that the implementation of this functionality depends upon vendor -specific extensions to the C++ language. So, there is no guarenteed 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. -It's reasonable to expect that future C++ compilers will support -these extensions or something equivalent. -
BOOST_CLASS_EXPORT.
+Export implies two things:
+
+BOOST_CLASS_EXPORT in the same
+source module that includes any of the archive class headers will
+instantiate code required to serialize polymorphic pointers of
+the indicated type to the all those archive classes. If no
+archive class headers are included, then no code will be instantiated.
+
+
+Note that the implemenation of this functionality requires
+that the BOOST_CLASS_EXPORT
+macro appear after and the inclusion of any archive
+class headers for which code is to be instantiated.
+So, code that uses BOOST_CLASS_EXPORT
+will look like the following:
+
+#include <boost/archive/text_oarchive.hpp>
+#include <boost/archive/text_oarchive.hpp>
+... // other archives
+
+#include "a.hpp" // header declaration for class a
+BOOST_CLASS_EXPORT(a)
+... // other class headers and exports
+
+This will be true regardless of whether the is part
+of a stand alone executable, a static library or
+a dyanmic or shared library.
+
+Note that including
+BOOST_CLASS_EXPORT
+in the "a.hpp" header itself as one would do with
+other serialization traits will make it difficult
+or impossible to follow the rule above regarding
+inclusion of archive headers before
+BOOST_CLASS_EXPORT
+is invoked. This is different than other serialization
+traits which would normally be included in same file
+as the class declaration.
+
+
+This system has certain implications for placing code in static or shared
+libraries. Placing BOOST_CLASS_EXPORT
+in library code will have no effect unless archive class headers are
+also included. So when building a library, one should include all headers
+for all the archive classes which he anticipates using. Alternatively,
+one can include headers for just the
+Polymoprhic Archives.
+Also, when making shared libraries, there is currently a restriction
+that only one such library can use BOOST_CLASS_EXPORT
+for any given type. All this will most likely make it inconvenient
+to include BOOST_CLASS_EXPORT
+as part of the header of the class to be serialized. So, the
+best way to use BOOST_CLASS_EXPORT
+is to include it in the same module which implements the class.
+
+
+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. +So, in practice, be prepared to register or export all classes with one +or more virtual functions which are serialized through a pointer. + +
+Note that the implementation of this functionality depends upon vendor +specific extensions to the C++ language. So, there is no guarenteed 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. +It's reasonable to expect that future C++ compilers will support +these extensions or something equivalent. +
BOOST_CLASS_EXPORT
+
+
+is not used, The serialization library imposes no special requirements
+that need be taken into account when distributing code among various modules.
+
+For static libraries, this is illustrated by
demo_pimpl.cpp
,
@@ -362,52 +406,91 @@ and
demo_pimpl_A.hpp
-where implementation of serializaton is completely separate
-from the main program.
+where implementation of serializaton is in a static library
+completely separate from the main program.
+
+
+For runtime linked libraries this is illustrated by one of the tests:
+
+
+test_dll_simple
+,
+and
+
+dll_A.cpp
+
+where implementation of serializaton is also completely separate
+from the main program but the code is loaded at runtime. In this
+example, this code is loaded automatically when the program which
+uses it starts up, but it could just as well be loaded and unloaded
+with an OS dependent API call.
+
+
extended_type_info
+for associating classes with external identifying strings (GUID)
+and void_cast
+for casting between pointers of related types.
+
+To complete the functionality of
+extended_type_info
+the ability to construct and destroy corresponding types has been
+added. In order to use this functionality, one must specify
+how each type is created. This should be done at the time
+a class is exported. So, a more complete example of the code above would be:
+
+
+#include <boost/archive/text_oarchive.hpp>
+#include <boost/archive/text_oarchive.hpp>
+... // other archives
+
+#include "a.hpp" // header declaration for class a
+
+// this class has a default constructor
+BOOST_SERIALIZATION_FACTORY_0(a)
+// as well as one that takes one integer argument
+BOOST_SERIALIZATION_FACTORY_1(a, int)
+
+// specify the GUID for this class
+BOOST_CLASS_EXPORT(a)
+... // other class headers and exports
+
+
+With this in place, one can construct, serialize and destroy
+about which only is know the GUID and a base class.
+
-Well, not quite.
+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
+lock-free thread-safe
+
+singleton
+
+described elsewhere in this documentation.
-There are a couple of global data structures for holding
-information of serializable types. These structures are
-used to dispatch to correct code to handle each pair
-of serializable types and archive types. Since this
-information is shared among all archives, there is
-potential for problems. This has been addressed
-carefully implementing the library so that these
-structures are all initialized before
-main(...)
-is called. From then on they are never altered. So
-there SHOULD be no problem having mulitple archives
-open simultaneously - be it from the same or different
-threads.
-
-Well, almost. -
-With dynamically loaded code - DLLS or Shared Libraries,
-these global data structures can be altered when a library
-is loaded or unloaded. That is, in this case, these
-globa data structures can be altered after
-main(...)
-is called. So if a thread is dynamically loading/unloading
-modules which contain serialization code while an
-archive is open there could be problems. Also, if
-such loading/unloading is happening concurrently
-in different threads, there could also be problems.
-
-It might not be easy to control this. Is possible that -some systems may not actually load modules until they -are actually needed. So even though we think that -there is not dynamic loading/unloading of such code -it could be occurring as "help" to manage resources. -On such systems, access to archive code would have -to be syncronized with some multi-threading construct -in order to be functional. +This singleton implementation guarentees that all of this shared +information is initialized when the code module which contains +them 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 +or shared library. So if the following is avoided: +
<boost/static_warning.hpp> supplies a single macro
+BOOST_STATIC_WARNING(x), which generates a compile time warning message if
+the integral-constant-expression x is not true.
++Note that if the condition is true, then the macro will generate neither +code nor data - and the macro can also be used at either namespace, +class or function scope. When used in a template, the expression x +will be evaluated at the time the template is instantiated; this is +particularly useful for validating template parameters. +
+It is intended that the functioning of BOOST_STATIC_WARNING(x)
+be identical to that of BOOST_STATIC_ASSERT(x)
+except that rather than resulting in a compilation error, it will result in
+a compiler warning. In all other respects it should be the same. So
+for more information on using BOOST_STATIC_WARNING(x)
+consult the documentation for BOOST_STATIC_ASSERT(x)
+here.
+
© Copyright Robert Ramey 2002-2004.
Distributed under the Boost Software License, Version 1.0. (See
diff --git a/doc/todo.html b/doc/todo.html
new file mode 100644
index 00000000..15cb3339
--- /dev/null
+++ b/doc/todo.html
@@ -0,0 +1,113 @@
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+ 
+
+ Serialization
+ To Do
+
+
+
+
+These are enhancements that the serialization library needs but have not been done.
+Some of these projects, though tricky, are not huge and would be suitable
+for someone who has a limited time to spend on them. In particular, they
+might be of interest as student projects such as the Google Summer of Code.
+
+Portable Binary Archives
+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.
+
+Its missing the following: +
+The first thing I did was include some of the serialization library tests. +It became immediatly 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 +to find bottlenecks in totally unanticipated places and fixing those +has always lead to large improvements in performance. I expect that +this project would have a huge impact on the utility of the serialization +library. + +
extended_typeinfo
+implemenation which presumes that all classes names have been exported.
+So, to make this library compatible for platforms without RTTI,
+a set of tests, examples and new manual section would have to be created
+
+Revised 1 November, 2008 +
© Copyright Robert Ramey 2002-2008. +Distributed under the Boost Software License, Version 1.0. (See +accompanying file LICENSE_1_0.txt or copy at http://www.boost.org/LICENSE_1_0.txt) +
+ + diff --git a/doc/traits.html b/doc/traits.html index cb127e41..fc7ca62c 100644 --- a/doc/traits.html +++ b/doc/traits.html @@ -179,7 +179,7 @@ Default tracking traits are: That is, addresses of addresses are not tracked by default.boost::serialization::nvp,
track_never.
- track_selectivly.
+ track_selectively.
That is addresses of serialized objects are tracked if and only if
one or more of the following is true:
BOOST_IS_ABSTRACT(my_class) to indicate
- that the class is an abstract base class. This will cause the compiler
- to avoid generating code that causes this error.
- This macro must be used in the global namespace, with full namespace
- qualification of the argument class.
-BOOST_IS_ABSTRACT(T)
+to do this. Not all compilers support this type trait and corresponding
+macro. To address this, the macro
+BOOST_SERIALIZATION_ASSUME_ABSTRACT(T) has been
+implemented to permit one to explicitly indicate that a specified
+type is in fact abstract. This will guarentee that
+BOOST_IS_ABSTRACT
+will return the correct value for all compilers.
+
IsWrapperis the type a wrapper?mpl::false_
mpl::true_mpl::false_
+namespace boost { namespace serialization {
+ template
+ struct is_bitwise_serializable
+ : public is_arithmetic
+ {};
+} }
+
+is used, and can be specialized for other classes. The specialization
+is made easy by the corresponding macro:
+
+BOOST_IS_BITWISE_SERIALIZABLE(my_class)
+
+
+=======
© Copyright Robert Ramey 2002-2004 and Matthias Troyer 2006. Distributed under the Boost Software License, Version 1.0. (See diff --git a/doc/tutorial.html b/doc/tutorial.html index b4fd3cdc..8154611f 100644 --- a/doc/tutorial.html +++ b/doc/tutorial.html @@ -123,7 +123,7 @@ int main() { gps_position newg; { // create and open an archive for input - std::ifstream ifs("filename", std::ios::binary); + std::ifstream ifs("filename"); boost::archive::text_iarchive ia(ifs); // read class state from archive ia >> newg; diff --git a/doc/void_cast.html b/doc/void_cast.html index 190964eb..51c0bae3 100644 --- a/doc/void_cast.html +++ b/doc/void_cast.html @@ -44,8 +44,8 @@ They are declared in the namespace template<class Derived, class Base> const void_cast_detail::void_caster & void_cast_register( - const Derived * derived = NULL, - const Base * base = NULL + Derived const * derived = NULL, + Base * const base = NULL )