assert()-like functionality in release mode

[Olaf van der Spek <OlafvdSpek@…>]

I think an assert() that also works in release mode would be good to have. There is too much code where errors aren't being handled properly. I think such a new assert() would lower the barrier to do error checking.

MFC has VERIFY(), although ignores failures in release mode. I don't think that's the best approach.

[Steven Watanabe]

The expansion of assert is controlled by the macro NDEBUG independently of optimization options. Because of the way assert is designed, it is always a bug if an assertion fails. This is due to more than just the fact that assertions can be disabled. It is also due to the fact that a failed assertion crashes the program. In addition, proper handling of errors that are not bugs is much more complex than assert is capable of handling.

[Olaf van der Spek <OlafvdSpek@…>]

Are you suggesting I just don't define NDEBUG? That's not an optimal solution, as leaving assert() enabled could give a performance hit, because it's usually expected to be gone in release mode. The app is supposed not to depend on assert expressions being evaluated, that's why there should be another construct that is not excluded (by default) in release mode.

I agree that it's certainly not suitable for all error handling. That doesn't mean there aren't a lot of situations where it would come in handy.

[olafvdspek@…]

Somebody? I'm willing to work on this one myself if the feature would be accepted into Boost.

[viboes]

Send a post to the dev ML requiring interest in the feature.

[Andrey Semashev]

There is the BOOST_VERIFY(x) macro, which is expands to x in release builds and BOOST_ASSERT(x) in debug. There is also BOOST_VERIFY_MSG. Note that these macros do not implement error handling in release builds.

If you want to do an actual error handling in release (e.g. abort in case of error) then asserts are not the right tool for this, IMO. Use exceptions or explicitly spell out the error handling behavior.