Robert Ramey wrote:
Since we've implemented this we do get a complaint on a regular basis - but we've not had a problem which had cropped up a couple of times before - creation of archives which cannot be read.
For those that use "const" on a regular basis this issue hardly every crops up. To accomodate the rest of us I might be convinced to implement:
BOOST_SERIALIZATION_NO_CONST_CHECKING which would suppress the check. This would help those who have an issue with using "const" but it wouldn't cut down the frequency of the incidences such as that started this thread.
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? Is it that one programmer serializes an object and another a pointer? Probably not. Could it be this: the default tracking behavior is "track_selectively". Possibly. 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!) 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. AFAICT (*), with that in place, there is not need for "traps". cheers -Thosten (*) It's been a long day of 10 hours work and 3 hours helping my big-brother with marketing assignment, so my brain might not work properly anymore :-)