Thorsten Ottosen wrote:
Robert Ramey wrote: (It is really hard to grasp why using a const-cast is really needed ... the connection is just to weak).
Actually, this is probably the heart of the problem. Regeneration of serialized pointers has a number of implications which are not at all obvious until you think about it. Among others is the fact that tracking is required to implement this and that this conflicts with other natural usages of serialization. The "real" solution would be cut down the functionality of the serialization to narrow its application to a set of usages which can't conflict. It's also possible that the "serialization traits" might have been designed differently to make eliminate that they be "in sync" or that other higher level traits might be designed instead (e.g. "log", etc....). Its also possible that implementation of a well crafted set of serialization "concepts" could be helpful. So I'm not totally unsympathetic to the complaints about this. And I do concede that it is slightly odd. Recognize that the current solution does in fact address a real problem and does force users to understand their choices in their usage of the library at the time when it can actually help rather than way after its too late. On the other hand, I suspect that this is a problem mostly for people who are not in the habit of using "const" everywhere they can. For those that are in this habit, the problem rarely comes up and when it does its easy to address. For those who aren't in this habit - it requires some sort of "ugly" casting. I confess I don't have much sympathy here. Why should the rest of us give up a useful double check just because other's don't use "const" enough. For those that don't agree - well, they always have the & operator to fall back on. In the context of an archive, this is identical to an << or >> without the "trap" Robert Ramey
-Thorsten