From: William E. Kempf (wekempf_at_[hidden])
Date: 2002-11-14 15:10:03
David Abrahams said:
> "Eric Woodruff" <Eric.Woodruff_at_[hidden]> 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
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
Boost list run by bdawes at acm.org, gregod at cs.rpi.edu, cpdaniel at pacbell.net, john at johnmaddock.co.uk