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