Robert Ramey wrote:
Thorsten Ottosen wrote:
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. ^^^^^^^^^ IMO the current policy of the library actually forces me to write bad/ugly code because if I ever want to serialize something in a non-const context I have to force it to const artificially.
This will be short because I know we've been over this point endlessly in the past, but I'll try one more time. Make a macro to control this behavior: BOOST_SERIALIZATION_CONST_STRICT or whatever. Make this optional. When someone posts an issue with an archive, tell them to recompile with this option turned on so that they can help find the problem. Then the rest of us can write normal code and the library will behave as expected. Less people will need to read the fine print of the library. BTW, I suspect the decrease in bug reports might be a result of less folks being able to get "hello serialization" to compile and subsequently giving up on the library instead of the 'better' code that this 'enforces'. Jeff