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
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
-- David Abrahams dave_at_[hidden] * http://www.boost-consulting.com Boost support, enhancements, training, and commercial distribution
Boost list run by bdawes at acm.org, gregod at cs.rpi.edu, cpdaniel at pacbell.net, john at johnmaddock.co.uk