Am 31.07.2014 04:53, schrieb Walter Bright:
On 7/30/2014 6:38 PM, Daniel Gibson wrote:
I'm in favor of a "harmless" assert().
In C(++) I sometimes use things like
assert(x != NULL);
if(x != NULL) {
x->foo = 42;
// ...
}
I have that assertion to hopefully find bugs during development and
fix them.
However, no program is bug free and so it's totally possible that x
*is* NULL in
some circumstance in the wild (in a "release" mode binary), so I want
to make
sure it doesn't explode if that happens but handle the problem more
gracefully.
It would be rather unfortunate if the compiler removed that second
check in
release mode because the assertion made it assume that x can't be NULL.
Your code is doomed to having problems using assert this way.
The behavior you desire here is easily handled by creating your own
template to exhibit it. See the implementation of enforce() for how to
do it.
Now that's a bit surprising to me, as you wrote in the other thread:
> 7. using enforce() to check for program bugs is utterly wrong.
> enforce() is a library creation, the core language does not recognize
> it."
Until now (being mostly a C/C++ guy), I saw assertions as a way to find
bugs during development/testing that is completely eliminated in release
mode (so I might still want to handle the asserted conditions gracefully
there) - and it seems like I'm not alone with that view.
Because (in C/C++) assertions just vanish when NDEBUG isn't defined, it
would never occur to me that they have any influence on such (release
mode) builds.
Doing optimizations on this would just lead to frustration, like several
kinds of optimizations recently have (e.g. this "compiler will remove
bzero() on memory that isn't used afterwards" bullshit).
Cheers,
Daniel
