Re: [boost] Re: Serialization Submission version 6

From: William E. Kempf (wekempf_at_[hidden])
Date: 2002-11-15 11:36:24

David Abrahams said:
> "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.

Most of the cases I've ever had a need for do.  Either it's being used to
persist data, or it's being used to do IPC.  Are the other uses really
prevalent in your experience?

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

OK, I may be wrong here.  However, it was my understanding that many
implementation returned nothing more than the type's name, minus the
namespace, which would mean you could easily get non-unique names.  I had
even heard a rumor once that there was a compiler that always returned a
null string, in order to save space in the executable, but I can't tell
you what compiler that was supposed to be or verify that it was anything
more than a bad rumor.

Regardless, however, you have to admit that all of this *IS* allowed by
the standard, making relying on this behavior to be shaky even if you
could confirm that all current implementations do something useful here.

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

If type_info:name() doesn't return a unique string?

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

That may well be worth looking into, but I'm not familiar with the
technique.  I know he generates unique integer ids (or at least, I think I
know that), but will the generation produce consistent ids across
application runs?  If not, regardless of whether or not serialization can
be useful with out that, I would claim it cripples the serialization
library enough to not be a valid solution.

William E. Kempf