Re: [boost] Re: Serialization Submission version 6

From: David Abrahams (dave_at_[hidden])
Date: 2002-11-14 18:58:01

"William E. Kempf" <wekempf_at_[hidden]> writes:

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

Not all uses of serialization depend on that.

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

Which implementations? Boost.Python v2 /depends/ on type_info::name()
returning a usefully-unique string on many platforms (depending on
their dynamic linking model). I've never seen an example of a platform
which "often give you strings that are *not* unique", but if they're
out there, I need to know about them.

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

There are lots of tasks you can do with a serialization library, and I
submit that a reasonable proportion of those tasks can take advantage
of type_info::name() on a useful number of compilers.

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

Maybe it would make sense to use Steve Dewhurst's typeof()
technique. At least that could help reduce the number of user-supplied
identifiers needed.

-- 
                       David Abrahams
   dave_at_[hidden] * http://www.boost-consulting.com
Boost support, enhancements, training, and commercial distribution