-----Original Message----- From: Vladimir Prus [SMTP:[EMAIL PROTECTED]] Sent: Sunday, November 10, 2002 5:52 AM To: Boost mailing list; Robert Ramey Subject: Re: [boost] Serialization Submission version 6
Robert, > I have just loaded the latest version of the serialization library >(serialization6.zip) > to the files section. > > changes from previous versions include: > > 1) A demo addressing the issue of plug-ins and global registration. I'm somewhat lost. To begin with, demo without a documentation is only 50% helpfull (or even less). Second, it does not answer my concerns. You seem to mean, that if I want to store classes by base pointers, then I should roll my own registration system? - Volodya If you want to create archives that store classes through base class pointers and the programs that read the archives can share the same header files you will have to register the classes used. In situations where the above is not possible, e.g. plug-ins, you must roll your own registration system. 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. Hmmm now we could have two classes with the same type_info id which are in fact different. A serialization system could not detect this difference and loading would fail. Basically, accross programs, class names are not guaranteed to be unique so any method of "matchiing" classess across programs using class names or some derivative there of is bound to be unsuitable for our purposes. 3) There is no automatic way of providing such a universal type identifier. Suppose we use something stronger - e.g. the whole class declaration. That should be sufficent - Or is it? First of all this wouldn't permit one to change class declarations with out changing its "identity". Hence newer class versions couldn't be matched with older ones. Class versioning (an indispensible concept) could not be implemented. Besides, the fact that two declarations might be identical in no way guarentees they have the same implementations accross programs. So the above still applies. 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. In the Microsoft method, an (18 digit?)GUID is generated on one's machine with a special program guarenteed (to one chance in a very large number) in time and spaceto be unique. This unique number is used by the programmer in all his programs that use a particular class. That is, the concept of "class identity" is addressed explicitly by the programmer. There is no automatic way to assign "class identity" By the way, given the number of digits in thier GUID, "unique in time and space" means time(longer than the age of the universe) and space (whole universe). No one has ever accused Microsoft of lack of ambition. End of argument I am aware that the above argument might not convince you. However you must concede that someone might agree with me. My example factors out the "class identity" issue. If you believe, in spite of the arguments above, that you have a portable implementation of type_info that can serve as a cross program class identifier, your free to use in the way the example does. If not, you can use any "class identity" system you prefer. 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. In this case, local class identifiers based on the sequence that class members are "seen" by the serialization system are sufficient and work well as experience of the many users of this system will attest. If you find the requierment to "register" derived classes distastful, you can use the example as a basis for your own local registration system. This should make everyone happy. Robert Ramey P.S. I would be glad to add comments to the demo if its unclear. I would might be willing to include information such as the above in the documentation. However, you seem to be the only person for whom this is a large issue. So I wonder about the value of this. RR _______________________________________________ Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
