"William E. Kempf" <[EMAIL PROTECTED]> writes:
> David Abrahams said:
>> "Eric Woodruff" <[EMAIL PROTECTED]> 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
[EMAIL PROTECTED] * http://www.boost-consulting.com
Boost support, enhancements, training, and commercial distribution
_______________________________________________
Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
