Serialization is the process of converting program data into a form that can be saved to persistent storage and later converting the stored data back into program data. This process is also referred to as persistence, since it moves data to and from persistent storage. Persistent storage is a data store that will hold the data even after the program exits or stops executing, or even if the computer is powered off. C++ does not have a serialization facility, so programmers have to either write their own serialization code or use a library.
There are several libraries that already provide serialization services, so you may be asking "why was this library created?" The main reasons are:
Create a portable, easy-to-use, and open source C++ library that uses state-of-the-art programming techniques with state-of-the-art C++ compilers such as GCC/G++ 4.x and Microsoft Visual C++ 2005 or later. The library can be built and executed on Mac OS X 10.4 or later, Windows XP or later, and POSIX systems such as FreeBSD and GNU/Linux. Other systems may work but are untested. There are no licensing fees for using this library.
Store data in a manner optimized for a SQL storage device, in particular, a SQLite3 database. SQLite3 is an engine that processes SQL commands to store and retrieve data in database tables in a disk file, ie, it acts as a database server even though it is linked to an executable as a library. Other serialization libraries either do not support a SQL backend, or do so while also having to support other formats such as text, binary or XML. Since they have to accomodate other formats, clients must often pass more metadata to those libraries to satisfy the requirements of the other formats. For example, when storing as XML, clients must give the library a text string for the names of the nodes that are written in the XML. This library, however, has no such requirement, because (1) it creates SQL table names by itself and tracks those names internally, and (2) it only targets a SQL backend. Clients therefore do not need to pass as much metadata to the library, which means that less work is needed by clients to use the library.
Produce compact data files. Object types are mapped to SQL tables so that objects of the same type occupy the same table, thus efficiently using the database's storage.
Allow the storage file to contain more than one sets of data. Many of the other serialization libraries allow one set of objects to be stored in each file, but this library allows clients to store as many sets of objects as they like, the only restriction being that each set must have a different name.
Provide support for as many C++ types as possible. For example, built-in types such as integer, arrays, pointers, etc., are supported. Support is also provided for many STL types such as string, pair, complex, set, vector, map, etc. Support is also provided for types in the std::tr1, stdext, Loki, boost, and Intel Threading Building Blocks libraries.
Avoid the use of any "code injecting" macros. Macros are mostly used to indicate the availability (or not) of third party libraries or C++ language features. For example:
#define HAVE_LOKI_LIBRARY 1
tells the library that support for Loki is wanted. And
#define USE_LOKI_LIBRARY 1
informs the library that it should use Loki for performing compile-time type traits tests.
Apart from these availability macros, the library has only one
other macro used for other purposes: the
CCS_DISABLE_POINTER_TRACKING_FOR macro, which does not
inject code into a class, and is used to declare that pointers should
not be tracked for a particular type. It's even possible to not use
this macro by copying the macro's text and manually substituting
it.