From: Sascha Friedmann (sascha.friedmann_at_[hidden])
Date: 2006-08-09 15:51:27
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?