Date: Tue, 26 Nov 2002 04:52:15 -0500 From: "Gennadiy Rozental" <[EMAIL PROTECTED]>
>> Some more elaborate registration system might be interesting and/or >> useful, and presumably some unique id could be passed to the >> serialization package, but beyond that it doesn't have to be used >> by the serialization system in any way. >The point is not to make "more eleborate" restration system. The point is to >separate it so that serilization will rely on some public interface only and >should not need to know implementation details. >> >> Nothing more is needed by the system so I don't see any benefit in adding >> in any more machinery of any kind. >The benefit is more flexible design, where you could switch to different >registration system without changing single byte in serialization library >code. the system to relate a type T to an integer encoded inside an archive and vice-versa is completely internal to the serialization system. Once it works, there can be no motivation to change it. If there is a better system, then it should be rolled into the library. I can see no reason why one would want to be able to switch between strictly internal implementations. The void_cast is something else and really separate from serialization - though serialization depends upon it. In this case, "registration" refers to saving information about class inheritance. This is totally disjoint from serialization. It is really implementation of a small part of reflection. If relection is implemented as a nice package, then void_cast would end up as part of that. It has nothing to do with the difference of opinion between "forward_declaration" and "global_registration" Robert Ramey _______________________________________________ Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
