From: Robert Ramey (ramey_at_[hidden])
Date: 2002-11-26 11:20:52
Date: Tue, 26 Nov 2002 04:52:15 -0500
From: "Gennadiy Rozental" <gennadiy.rozental_at_[hidden]>
>> 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
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"
Boost list run by bdawes at acm.org, gregod at cs.rpi.edu, cpdaniel at pacbell.net, john at johnmaddock.co.uk