checkedint call removal

[Walter Bright via Digitalmars-d]

On 7/31/2014 3:23 AM, Tobias Müller wrote:
> Walter Bright <newshound2 at 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.