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