checkedint call removal
Paolo Invernizzi via Digitalmars-d
digitalmars-d at puremagic.com
Sun Aug 3 02:27:20 PDT 2014
On Saturday, 2 August 2014 at 22:00:27 UTC, Andrew Godfrey wrote:
> On Saturday, 2 August 2014 at 21:36:11 UTC, Tobias Pankrath
> wrote:
>> On Saturday, 2 August 2014 at 21:25:40 UTC, Ola Fosheim
>> Grøstad wrote:
>>> On Saturday, 2 August 2014 at 20:27:09 UTC, Andrei
>>> Alexandrescu wrote:
>>>> Hmmm... code that fails assertions is hardly working. --
>>>> Andrei
>>>
>>> It is not the code that fails the assertion, it is the
>>> asserted proposition that has not be satisfied by the axioms
>>> in the program as it has been formulated in the context. It
>>> does not mean "can not be satisfied", but "has not been
>>> satisfied".
>>
>> Don't you agree, that a program that throws AssertError in non
>> -release* build is broken?
>>
>> * this is not the opposite of debug
>
> By this definition of 'broken', I assert that most shipped
> software is broken.
I strongly disagree with that: if there's pressure for a release,
most software in that condition has the assert _removed_ or
_commented_, a bug opened, and a boss directive to do so so that
it's boss responsibility having taken the risk.
The assert is _reinserted_ or _uncommented_ when there's someone
hunting for that bug after the release.
If this operation can't be done because the failing asserts are a
bazillion, compiling it in '-release' with the proposed
assert/assume semantic don't change anything: from time to time,
when the snowball of failed assert-optimisations will start to
destroy the program logic, all that thing will explode in the
face of the user.
---
Paolo
More information about the Digitalmars-d
mailing list