Thorsten Ottosen wrote:
This issues seems to pop up again and again.
It's true that from time to time this question comes up. Though not very often it seems to me. On the other hand, since I've put this in I havn't had anyone complain that they've invalid archives (well maybe a couple of times due to bugs in in serialization code - but that's different.) which was a big pain in the rear to try to explain before.
It's just *so* surprising (nobody reads through all the docs of a library when they start to use it).
As you remember, I had to contact you personally to help me with Pointer Container Serialization --- it was not because I hadn't tried before contacting you (I spent hours trying to figure out what was wrong). (I have documented a seperate todo-list for people using Boost.Pointer Container and serialization just to remember them of this isssue!).
There has to be a better way. I read through your scenario again:
http://www.boost.org/libs/serialization/doc/rationale.html#trap
and I don't get very much of it.
I understand the need for ensuring
1. no invalid archives are created. 2. no data is lost. 3. no runtime errors occur.
but there has to be a better way, even if it means 3 becomes a runtime exception.
Hmmm - to ensure 2) that would have to occur on archive save - I'm not even sure that's possible. Even so it lot harder to track down than the current setup.
Somehow the information of a class and how it is serialized must be localized ***in one place only*** so one programmer can't ruin the archieve of another programmer without his knowlegde.
In my view all that should be in the header module which declares the class. This is always possible and that's what I always do. It's always grouped together in one place in one module. Personally I don't understand why everyone doesn't do it that way. Maybe we need a macro which specifes all the serialization traits for a type like BOOST_CLASS_TRAITS(tracking, abstract, etc...) rather than just letting people sprinkle them will-nilly all over their code.
If this means
1. that by default, you can't serialize a pointer (you must ask for it), 2. that by default, you have to define BOOST_SERIALIZATION_TRACKING
BTW: I'm ok with
T * t; ar >> t;
failing (just make it part of the toturial). That's completely
different from reading from an object.
Hmm - I'm doubtful that would be a popular idea. But, you want to establish a different default policy for your own company, you could easily tweak tracking.hpp so that the default would be track_never, - but then you'll get a trap when you try to serialize a pointer - which I guess would be what you want. We've had some experience with this and from my standpoint its been positive. This was discussed at length and I've conceded that knowledgable people can disagree on this point. So I do have a couple of ideas which mollify those who disagree on this point. a) I could change the BOOST_STATIC_ASSERT to BOOST_STATIC_WARNING This would emit an warning message on most compilers. Then people are free to ignore it. Of course from one standpoint its worse, some people will complain about the warning then ignore it and then complain again about creating an unreadable archive - LOL. So I'll have the worst of both worlds. b) We could make the emmision of the message (assert or warning) conditional or suppressable via definition of something like BOOST_SUPPRESS_WARNINGS (which could be part of BOOST_STATIC_WARNING). The argument that people don't/won't read the documentation doesn't evoke much sympathy from me. On one hand we want to permit someone to make an egregious error so that he won't have to read the manual to understand the nature of his error. I don't buy it. In the code where the static assertion occurs there is a pointer to the explanation in the manual. It bother's me much less to have someone complain about this error than it does getting email titled "bug in serialization" from people "too busy" to read the portion of the manul pointed to by the comment in the line where the error message is emitted. I want everyone to be successful using the library - even if they complain that it requires them to write good code. Robert Ramey