Re: [boost] Re: Serialization Submission version 6

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
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