David Abrahams said: > "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.
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 _______________________________________________ Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
