From: Gordon Woodhull
I've looked at the code now (it's very clear!), and I understand what the assertions do: they double-check that the error handler is fulfilling the contract of not returning if the constraint fails.
Right.
I think this is a valuable feature in debug mode but would not be wanted 1) in performance critical apps (the extra test matters)
I thought in that case one would turn assertions off globally.
2) if we've established that there's no way a floating point predicate is always going to provide consistent results. (I know you're laying your hopes on consistent truncation.)
Right, but I will try to elegantly solve it for this case too. ;-)
Of course, if you allow the asserts to be disabled by macro or policy, then you're also allowing the monitored values use case. I understand that you don't want to support this (certainly the nomenclature is wrong), but it would be nice if you would allow people to experiment.
Got it.
BTW, I find the ignore example confusing because it's checking whether the old value still satisfies the constraint. (Doesn't it know this by now?) To be honest, I had to compile it and say "huh?" to figure this out.
The explanation in the tutorial covers this, is it not clear enough and should be improved?
This results in three invocations of the predicate on a successful assign.
Yes, one of them being the assertion. The policy in the example is protective and tries to prevent construction of invalid object even in non-debug mode. It could be empty and then this situation would be handled by the assertion, leaving only one predicate call in release mode. Best regards, Robert