Re: [boost] Re: Serialization Submission version 6
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
[boost] Re: Serialization Submission version 6
Vahan Margaryan wrote: Eric Woodruff wrote: type_info is not portable in the slightest. I realize that. I just pointed out that it's not so convenient to have user-supplied string ids because of the template classes. As pointed out by Robert, the user-supplied string id could be made optional. For the lazy user we might imagine a default value obtained in some programmatic way, for example a possibly pre-processed type_info::name(). Alberto Barbati ___ Unsubscribe other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
[boost] Re: Serialization Submission version 6
Robert Ramey wrote: register_cross_program_class_identifierclass T(const char *id=T) An alternative could be to use register_type as it is, but augment the serialization traits class to provide a const char* serializationT::get_cross_program_class_identifier(); This solution has the advantage that the identifier string can be physically located near the load/save/version functions (which are usually near the class itself). Alberto Barbati ___ Unsubscribe other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
[boost] Re: Serialization Submission version 6
type_info is not portable in the slightest. Vahan Margaryan [EMAIL PROTECTED] wrote in message news:003401c28bee$7fbc4f40$4f09a8c0;lan.mosaic.am... - Original Message - From: Robert Ramey [EMAIL PROTECTED] Sent: Thursday, November 14, 2002 5:45 PM Subject: Re: [boost] Serialization Submission version 6 register_cross_program_class_identifierclass T(const char *id=T) This would be invoked for each class declaration. Now we have a portable id associated with each class - exactly what we need. Polymorphic pointers would archive this tag and use it to determine the proper class to construct on loading. The default class identifier would be the text representation of the class name. (note: in general not necessarily the same as type_info.name() ) which is going to be sufficent for almost all cases. The problem that usually arises from this is having to make up class ids for template classes. type_info does this for you. Regards, -Vahan ___ Unsubscribe other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
Re: [boost] Re: Serialization Submission version 6
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. -- 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
Re: [boost] Re: Serialization Submission version 6
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. 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. 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. 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. William E. Kempf ___ Unsubscribe other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
Re: [boost] Re: Serialization Submission version 6
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. 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. 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. 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. -- 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
