Robert Ramey wrote:
Thorsten Ottosen wrote:
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.
These three bullets are taken from your documentation of what teh benefits of your current setup is. I just don't get why serializing a non-const object can lead to them.
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.
Write a section in your tutorial called "Serialization best practices". If all that is needed is to always put serialization "derectives" together with the class declaration, that's a pretty cheap fix.
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.
Your docs state that this will fail when tracking has been set to something!
But, you want to establish a different default policy for your own company,
no, I don't want to do that. I want people to use your library and not turn it down because they can't get hello world to work.
The argument that people don't/won't read the documentation doesn't evoke much sympathy from me.
Well, people read documentation, but there is a limit to how much new stuff a programmers brain can taker per day. Not many read it all and remember it all.
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.
I certainly couldn't find that. Otherwise I wouldn't have asked you personally.
I want everyone to be successful using the library - even if they complain that it requires them to write good code.
If good code means "put serialization meta information with the class declaration", I agree. If you mean a << add_const( obj ); I don't agree. -Thorsten