Thorsten Ottosen wrote:
Hm. I have a certain feeling that the "trap" is somewhat misplaced.
First of, any solution that is **so** complicated to explain as http://www.boost.org/libs/serialization/doc/rationale.html#trap tells my intuition that something is not clearly understood yet.
Question: what is the real problem here?
Could it be this: the default tracking behavior is "track_selectively". Possibly.
That's it. This would be the behavior that I would expect most programmer's desire. That's why I made it the default. But (like other cases where a default is used), it can create unintended side effects. Hence the trap to make at least one such side effect visible.
Your looong example ends with this text: "Eventually, after some code restructuring, the differing requirements of serializating construct_from are reconciled."
But what do the programmers end up doing? I'm very curious? Is it not possible to what the programmers in the example is trying? (I'm too stupid here, but I thought it might be possible!)
Basically serializing through a pointer requires tracking to guarentee that that the de-serialized structure replicates the original. So serialization through a pointer conflicts with tracking turned off. One programmer has trackng turned off to make a log entry while another needs to serialize a pointer to an instance of the such an entry. There are a number of ways to handle this. a) they could arm wrestle and the loser changes his code. b) they could define different types - perhaps with a common base class. This would allow different attributes in each usage. c) some other way that hasn't occured to me.
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.
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. This is really a question about the usage of defaults and automatic behavior in general. The function of such default/automatic behavior is to make something easier to use correctly. But taken too far it can lead to opaque behavior that is hard to understand and modify. In my opinion BJAM suffers from this. In this case, I think after all this time that the usage of default settings as well as the settings themselves are "about right". Given how complex the library can/could be to use, its amazing to me that so few issues come up. Robert Ramey