
|
Serialization
extended_type_info
|
Motivation
The serialization library needs a system like
type_info/typeid()
to perform
the following functions
-
given a pointer to a type T discover the true type pointed to.
-
given an "external" key - determine what type of object to create.
The problem with std::type_info
-
The main function we require -
std::typeid()
is not available in all environments. Support for this function depends upon
runtime typing(RTTI) support from the compiler. This may be non-existent
or not enabled for reasons such as a percieved inefficiency.
-
std::type_info
includes a string
containing type name. This would seem to satisfy 2) above.
But the format of this string is not consistent accross compilers, libraries,
and operating systems. This makes it unusable for support of portable archives.
-
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
different applications. In fact, including different headers in different
name spaces is an accepted method used to avoid name space conflicts.
Thus the namespace::class_name can't be used as a key.
-
We may want the ability to serialize objects through a base class even though
they have no
virtual
function. That
is, objects of classes which are not polymorphic in the strict C++ sense. This
is not supported by the standard system.
-
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
mechanism support inter-operability accross different type id systems.
Features
extended_type_info
is and implementation
of std::type_info
with the following features:
-
Maintains a global table of extended_type_info records - one for each type known
to the program.
-
Permits several different type id systems to inter-operate.
-
permits association of an arbitrary key with a type. Often this key would
be the class name - but it doesn't have to be. This key is referred to as
a GUID - Globally Unique IDentifier. Presumably it should be unique in the universe.
Typically this GUID would be in header files and be used to match type accross
applications.
-
permits the "mixing" of type info systems. For example, one class might use
typeid()
to find the external identifier
of a class while another might not.
This library includes two different type id systems:
-
extended_type_info_typeid
which is implemented in terms of the standard
typeid()
.
-
extended_type_info_no_rtti
which is implemented in a way that doesn't rely on the existence
RTTI. However, it does require that all classes for which type id is to be used
be explictly assigned an external key - which otherwise would be optional.
Usage
Implemenation
© Copyright Robert Ramey 2005.
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)