Robert Ramey wrote:
Thorsten Ottosen wrote:
Anyway, it might be worth considering this procedure:
1. There is no default tracking level. It must be set explxitly for all classes. It should be part of a class' public interface that you know it is serializable and that you know *explicitly* what tracking it supports.
Maybe this can be implemented as a macro that must expand inside the class, so it can only be provided with the declaration of the class.
This would require that one have access to the class definition inorder to serialize an instance. Thus one of the main requirements of the library would have to be set aside. This is essential to things like defining serialization.
Well, it could be made such the macros that work outside the class, check the class for presence of the internal macro.
AFAICT (*), with that in place, there is not need for "traps".
You're probably correct here. In this case, the second programmer changes the tracking behavior and breaks the others code at compile time. (similar to what we have now - but more obvious) Still we would have to explain why this happens - no net gain in my view.
Well, wouldn't it mean that we could get the error to point at the macro-definition, instead of some obscure place? (It is really hard to grasp why using a const-cast is really needed ... the connection is just to weak). -Thorsten