On 7/31/2014 3:23 AM, Tobias Müller wrote:
Walter Bright <newshou...@digitalmars.com> wrote:
On 7/30/2014 10:16 PM, bearophile wrote:
But you have redefined "assert" to mean a mix of assume and assert.
I haven't redefined anything. It's always been that way. It's used that
way in C/C++ (see your Microsoft C++ link).
Actually I cannot find anything in (the latest draft of) the C standard
that would allow that. There's no mention of undefined behavior if an
assertion is not met with NDEBUG defined. It's clearly defined what the
macro should expnd to in that case.
Yes, you are correct about that. But I suspect that is an artifact of the C
standard, and its long history of compilers that did essentially no optimization
at all (my C compiler was the first DOS C compiler to do data flow analysis).
The C standard was written long after C was ubiquitous, and tended to simply
document what compilers did.
If you look at the Wikipedia article,
http://en.wikipedia.org/wiki/Assertion_(software_development)
you'll see a more high level view of what assert is all about, rather than a
worm's eye view the C standard takes. (It even uses C for its examples.) Up
until this thread, I've never encountered someone who thought differently about it.
You might also want to consider Hoare's seminal paper on the topic published in
the 1970's, which my view adheres to. Then there's the extensive literature on
asserts for contract programming, again with the same view of asserts.
Consider also Meyers' comprehensive tome on the topic "Object-Oriented Software
Construction" (1997) where he writes:
"A run-time assertion violation is the manifestation of a bug in the software."
-- pg. 346
There isn't any weasel-wording there, there is no hint of an assert not actually
having to be valid if the program is optimized, etc.
