David Abrahams said: > "Eric Woodruff" <[EMAIL PROTECTED]> writes: > >> type_info is not portable in the slightest. > > There are lots of applications where that doesn't matter. And with a > little postprocessing, the type_info::name() produced by most > compilers could easily be normalized into a common format.
The trouble is that serialization requires an identifier that's persistant across application runs. type_info by itself doesn't help here, because you can't persist the type_info instance even if it were gauranteed to compare across runs (obviously it's not). type_info::name() is so underspecified that you can't be sure it won't give you the same string for every type. More importantly, in practice (i.e. implementations do this), type_info::name() will often give you strings that are *not* unique, rendering it worthless for this domain. Can type_info::name() be useful? Yes, provided the implementation did something useful, but it's not portable, and not useful for the task at hand. BTW, there's a LOT to be said for specifically supplying an identifier when implementing a persistence/serialization library, even though it means tedious busy work. Specifically, it allows you to insure the id is valid across multiple programs, regardless of how the implementation might auto-magically generate an identifier. I'd recommend choosing a "large integer" representation instead of a string, however, since it will take less space to represent externally. The GUID type is actually a fairly good choice here. William E. Kempf _______________________________________________ Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
