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 _______________________________________________ Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
