Re: [boost] Re: Serialization Submission version 6

From: David Abrahams (dave_at_[hidden])
Date: 2002-11-15 12:28:11

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

> David Abrahams said:
>> "William E. Kempf" <wekempf_at_[hidden]> writes:
>>
>> 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?

No, I didn't claim they were. I'm just saying that they exist. Where
applicable, it's important to be able to avoid a lot of extra work
writing registration code.

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

Yep, it's legally shaky. I think it's relatively portable, practically
speaking.

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

No, but show me one example which doesn't. My point is that most
compilers do emit unique strings for all practical purposes. Most even
do something human-readable.

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

Yes. It's a compile-time encoding. You have to register the UDTs, but
composite types such as T**** and T (*)(U,V) get unique type ids
automatically.

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