Robert Ramey wrote:
Sascha Friedmann wrote:
I understand now the problem, but in my real project I ran again into this trap. After rereading the article in the rationale I understand fully why it is trapping, but I don't want to set my class to track_never because I can't guarantee that it is what I want.
Hmm - you want to make unmaintainable code? If this is what you want - just comment out the trap in your own copy of iserializer.hpp and you'll be done.
For now I set them to track_never. I'm not 100% sure but for now it serves for me and when I need to save through a pointer the trap will show me that I have to refactor my broken code.
const_cast is no solution, too.
Why not? It's explictly designed to permit override of "const" where the user is more knowledgable than the library writer regarding what he want's to do. That's the situation here. It might also serve as a "red flag" for the programmer which has to fix your program in the future when it breaks.
Well, when I'm using a const object I have to cast the constness away before I can make a call to any non-const member-function and when I have to cast the constness away before searializing how comes it that the library knows at all, that this object is in reality a const object?