On 8 October 2013 13:17, Thorsten Ottosen
We are indeed going in circles. I can respect that some people don't want the overhead of the runtime check. I can also respect that people don't want to take down the whole server because of a bug in some subsystem.
Except you can't know if it is a bug in a subsystem or somewhere else. If you know the bug is from the subsystem, why did you put the bug in? And if you don't know the root cause of the bug, how can you possibly know the effect? All you've detected is a symptom. The rest of the "analysis" is nothing more than wishful thinking.
We just need to find a way to give both camps what they want, since both a valid use-cases.
No, we don't. Decide if your API has preconditions or not. For instance, the real difference between vector::operator[] and vector::at() is that the former has a precondition while the latter does not. If you define the behavior, it isn't a precondition, precisely because you are explicitly allowing it, and a correct program can call it with any value it likes. This is, of course, one of the many hard parts of library design. Make strong choices. Making it "configurable" whether or not something is a precondition is a weak choice. This, of course, doesn't mean you can't be friendlier if/when you detect a precondition violation in debug mode. But be very clear that it is a precondition violation resulting in undefined behavior. -- Nevin ":-)" Liber mailto:nevin@eviloverlord.com (847) 691-1404