Boost logo

Boost :

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, gregod at, cpdaniel at, john at