That's not exactly correct. From the link sited: "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." So the extended_type_info is a USER rather than a SUPPLIER of ag GUID. One of the main functions of BOOST_CLASS_EXPORT_GUID is to associate at type with type with a portable GUID. The specific GUID is left up to the user. The macro BOOST_CLASS_EXPORT(class name) just uses the class name as the GUID. So the existence of an open, portable GUID would complement extended_type_info rather than conflict with it. This system let me isolate serialization from having to address a number of issues related to comming up with a GUID. Among those are: a) it would seem attractive to make a GUID derived from typeinfo as provided by RTTI. In practice this doesn't seem attractive since there is no standardized typeinfo format. b) namespaces: the same type might appear in different namespaces in different programs. In fact, one of the uses of namespaces is to "wrap" libraries so that it can be guarenteed not to accidently conflict. c) Having the GUID look like a class name is attractive - but then it runs into character set issues. d) Having the GUID be derived from the class declaration might seem attractive, but what bout when the class changes - we don't want to obsolete all the programs which depend upon it - or do we? and others. So what starts out seeming like a simple idea, starts to get pretty complicated as one tries to realize it in a specific way. So - the extended_type_info - and by implication the serialization library takes a pass - it presumes you've got your own GUID or are happy with using the class name. And this shows up as a problem from time to time as user want to use classnames including a namespace as the GUID which conflicts with HTML. Robert Ramey Janek Kozicki wrote:
Andy said: (by the date of Thu, 9 Nov 2006 15:57:31 +0000 (UTC))
Thanks Sebastian,
The file I downloaded was GUIDv3.zip, as I couldn't find anyother (did I go to the wrong place: boost-consulting.com/vault ?).
GUID which stands for Global Uniqie IDentifier is already in boost. Why include a second one? If you want to work on this, then better improve the existing one.
For the beginning, it can be separated from lirbary boost::serialization (it is an extended_type_info):
http://boost.org/libs/serialization/doc/extended_type_info.html
In fact it is already a separate module (because it makes testing much simpler), so the separation will just make things more formal, and involve just changing namespaces.