"Robert Ramey" <ramey@rrsd.com> writes:
This is exactly the thing I'm thinking about. Without the trap, the user would have no clue that he is doing something he really doesn't intend to do. Of course he might say "I want to track it anyway" or he might say - well maybe in this example but ...
That might make sense if the set of circumstances you trap actually had a relationship to the set of problematic circumstances, but it doesn't. It's almost like choosing a random set of cases in which to issue a diagnostic in order to "force the user to think about what she's doing." (**) The only difference here is that you're telling the user which cases will cause the diagnostic. She may preemptively const-ify all of her tracked serializations, but how will that help? Adding const doesn't prevent any bugs; it just silences your diagnostic. (**) I don't intend to imply that you used those words, but I read them often in postings from those who want to deny users abstraction: exception-handling, garbage collection, classes, operator overloading, etc. Yours seems like a similarly patronizing approach. -- Dave Abrahams Boost Consulting www.boost-consulting.com