Re: [boost] Serialization Submission version 6

From: Vladimir Prus (ghost_at_[hidden])
Date: 2002-11-12 04:19:33

Robert Ramey wrote:

> After much thought on the questions you have raised I have come to 
> conclude the following:
> 
> 1) type_info is not portable
> 2) type_info can never be used as as a universal external type identifier
> 3) There is no automatic way of providing such a universal type identifier.
> 
> Arguments
> 
> 1) type_info is not portable
> 
> This point of fact is made in all references so I don't believe this is in dispute. 
> 
> 2) type_info can never be used as as a universal external type identifier
> 
> Suppose  type_info where made portable - For example, suppose that a string containing
> namespace, class name, and base class names were used.  At first blush this might 
> seem to work.  But the same class is used in another program in another
> namespace so we better remove the namespace.  

How's that? I'm I going to use the class from two different problem, I'll use the
same header, and the classes will be in the same namespace.

Anyway, let's move away from theoretical discussions. I'm developing for gcc, and
there's always 1<->1 mapping between type_info and class. I'd like to exploit this
fact, so see below.

> 3) There is no automatic way of providing such a universal type identifier.
> 
[snip]
> This leads to the conclusion that "class identity" cannot be resolved merely by
> inspecting program header code - which is all the compiler can do.
> 
> I believe that it is for this reason that type_info was made "non-portable".  Trying to
> make it portable would serve no useful purpose.
> 
> I also believe that this is the motivation for microsoft using GUID (Globally Unique Identifier)
> for its "plug-in" implementation - COM (Common Object Model).  I don't know about CORBA
> but I would guess it has some sort of analogous method.

Actually, GUID support "classes" developed in different languages and having no knowledge
about each other --- much fancy that serialization.

However, the mention of GUID gives me a new ground for argumentation. Suppose *I* (i.e.
without any help from serialization library), have created two maps:

    1. type_info -> GUID
    2. GUID -> factory function

I believe this is enough to correctly serialize/deserialize all classes registered
in those two maps. Your plug-in example suggests that load method for the base class
should take care of saving GUID and load method should dispatch to the appropriate
factory function. I think this only requires extra work from me, and is not needed.
In fact, the library might care of it. If a class with declared GUID is saved, than
GUID is safed as well. On loading, if object in archive has GUID, you call appropriate
factory function and then proceed with loading into created object.

I don't know how hard it will be to implement it be, but the interface is clear.
There's are two global maps, storing this information. In addition you can
pass additional map to archive's constructors.

What does it give us? First, support for plugins becomes very simple: I only have to register
GUID for classes there -- no need to write any custom load code.

Second, I can write a macros "register_class", which will:
1. Take type_info
2. Generate GUID from it (MD5 checksum, for example)
3. Update the maps appropriately.

And... I seem to get *everything* working as I like. Of course, this somewhat contradicts the
way classes are stored now. But I don't see other way to suit my requirement in scope of
your library. All other parts of library (to which I have no objections) are unchanged.

> This issue only occurs in "plug-ins" where classes need to be created by programs that don't have
> access to the class headers of the derived classes. If your importing class header in each program
> that uses your class, the whole issue is moot.  

As I was saying all the time, including all of the headers in the project in "main.cpp" is
not a reasonable idea for me. Please let me know if we can do something like I've described
above.

- Volodya