4 ms·
> How could you possibly check this using types that cannot represent what you are checking for? `f(u32 a, u32 b) { assert a > b ... ` (if the hypothetica
by chromatin 5y ago
> How could you possibly check this using types that cannot represent what you are checking for?
`f(u32 a, u32 b) {
assert a > b
...
`
(if the hypothetical following operation is `a-b` as discussed higher in the thread)
- pjmlp 5y agoBetter ensure that assert is not turned off in release mode then.
- raverbashing 5y agoOne of the reasons I don't like asserts. Log the error and act accordingly, instead of believing this kind of issue only happens during development
- jstimpfle 5y agoHow do you "act" if you detected your logic is faulty? In many situations aborting is the best choice. If input data is faulty and the reason for that is not seen as part of your logic, then sure, log an error and skip. I used to define my own assert macro to "ensure" my asserts aren't disabled, but I don't bother anymore. There's nothing wrong with assert, and you needn't define NDEBUG. It's important to be aware that there are different situations, and not all warrant aborting, as described above. Another differentation is that there can be asserts that must be disabled in release builds for performance reasons, and others that won't affect performance and can stay enabled.