4 ms·

I've always found the name `assert()` to be particularly bad. Many people do not know that their compilers optimise away assertions in `-O` ("release") builds.

by nh2 8y ago

I've always found the name `assert()` to be particularly bad. Many people do not know that their compilers optimise away assertions in `-O` ("release") builds. They use assertions for control flow and input validation, which is very wrong. I believe that could be trivially fixed by giving functions proper names that indicate what they do or what they are intended for. For example, calling such an optimised-away assertion function `debug_only_assert()` would immediately rule out such unintentional misuse.

pmorici 8y ago
Ha, reminds me of the time I was working on a project that worked great in debug mode and then crashed and burned when they went to compile it in release mode. Turned out someone had put the call to the initialization code inside an assert function. The bug took some time to figure out because all the crashes happened in code that was nowhere near the actual problem and of course when you turned on debugging the problem disappeared.
strmpnk 8y ago
While I'm still a fan of the name `assert()`, one alternative that I like is `invariant()`. It seems to capture the idea a little better. The debug vs release build is a bit of a problem still but I think part of the issue is around the idea that debug builds are too slow to use at all or take so long to build anyway so you might as well use release optimizations. This is something to address with faster compilers and better teaching (and perhaps encouraging folks to try learning how to use debuggers effectively).
senderista 8y ago
That’s exactly what Rust does (debug_assert() is stripped from release builds, assert() stays).
masklinn 8y ago
> I believe that could be trivially fixed by giving functions proper names that indicate what they do or what they are intended for. For example, calling such an optimised-away assertion function `debug_only_assert()` would immediately rule out such unintentional misuse. That is Rust's tack: > [assert!] assertions are always checked in both debug and release builds, and cannot be disabled. > Unlike assert!, debug_assert! statements are only enabled in non optimized builds by default. An optimized build will omit all debug_assert! statements unless -C debug-assertions is passed to the compiler.
technion 8y ago
Huh? I was worried I had been doing this wrong this whole time, but I haven't been able to replicate that with release builds. https://gist.github.com/technion/7c74fad9efd1f14244e25a1cee372a0e https://gist.github.com/technion/7c74fad9efd1f14244e25a1cee3...
- zmodem 8y ago
  In many settings, "release build" implies passing -DNDEBUG, which disables the asserts.
pix11 8y ago
This is misinformation: assert() is disabled if NDEBUG is defined, which is usually done on the command line. In sane build systems the command line is visible by default. Non-sane build systems display wrong percentage numbers instead, but that is a different topic.

by nh2 8y ago

pmorici 8y ago

Ha, reminds me of the time I was working on a project that worked great in debug mode and then crashed and burned when they went to compile it in release mode. Turned out someone had put the call to the initialization code inside an assert function. The bug took some time to figure out because all the crashes happened in code that was nowhere near the actual problem and of course when you turned on debugging the problem disappeared.

strmpnk 8y ago

While I'm still a fan of the name `assert()`, one alternative that I like is `invariant()`. It seems to capture the idea a little better. The debug vs release build is a bit of a problem still but I think part of the issue is around the idea that debug builds are too slow to use at all or take so long to build anyway so you might as well use release optimizations. This is something to address with faster compilers and better teaching (and perhaps encouraging folks to try learning how to use debuggers effectively).

senderista 8y ago

That’s exactly what Rust does (debug_assert() is stripped from release builds, assert() stays).

masklinn 8y ago

> I believe that could be trivially fixed by giving functions proper names that indicate what they do or what they are intended for. For example, calling such an optimised-away assertion function `debug_only_assert()` would immediately rule out such unintentional misuse. That is Rust's tack: > [assert!] assertions are always checked in both debug and release builds, and cannot be disabled. > Unlike assert!, debug_assert! statements are only enabled in non optimized builds by default. An optimized build will omit all debug_assert! statements unless -C debug-assertions is passed to the compiler.

technion 8y ago

Huh? I was worried I had been doing this wrong this whole time, but I haven't been able to replicate that with release builds. https://gist.github.com/technion/7c74fad9efd1f14244e25a1cee372a0e https://gist.github.com/technion/7c74fad9efd1f14244e25a1cee3...

zmodem 8y ago
In many settings, "release build" implies passing -DNDEBUG, which disables the asserts.

pix11 8y ago

This is misinformation: assert() is disabled if NDEBUG is defined, which is usually done on the command line. In sane build systems the command line is visible by default. Non-sane build systems display wrong percentage numbers instead, but that is a different topic.