On Fri, Aug 01, 2014 at 04:08:56PM +0200, Daniel Gibson via Digitalmars-d wrote:
> Am 01.08.2014 05:17, schrieb Walter Bright:
> >
> >Frankly, it never occurred to me that it wasn't obvious. When
> >something is ASSERTED to be true, then it is available to the
> >optimizer. After all, that is what optimizers do - rewrite code into
> >a mathematically equivalent form that is provably the same (but
> >cheaper to compute). Its inputs are things that are known to be true.
> >
> >For example, if a piece of code ASSERTS that x is 3, thereafter the
> >optimizer knows that x must be 3. After all, if the optimizer
> >encounters:
> >
> >    x = 3;
> >
> >do I need to then add a note saying the optimizer can now make use of
> >that fact afterwards? The use of "assert" is a very strong word, it
> >is not "maybe" or "possibly" or "sometimes" or "sort of".
> >
> >When you write:
> >
> >    assert(x == 3);
> >
> >then at that point, if x is not 3, then the program is irretrievably,
> >irredeemably, undeniably broken, and the default action is that the
> >program is terminated.
> >
> >The idea expressed here by more than one that this is not the case in
> >their code is astonishing to me.
> >
> 
> Well, this all sounds sane and makes sense in a way.
> 
> The thing is, I never considered assert() to mean this up to now,
> which is probably influenced by the following reasons:
> 
> In programming I've always encountered assert() in an "check if
> assertions are enabled/you're in debug mode, do nothing otherwise" way
> (that's what C, C++, Java and Python do).

Whoa. I've never heard this before, but yeah, it explains a lot. :-O

I suppose people have come to associate assert with the way it's
implemented in C/C++, and may not have been aware of the rationale
behind it. That's kinda scary.


> In unit tests the "checks" are also often called assertions.
[...]

Yes, because if those checks failed, it means your program isn't
conforming to the unittests, which means it is horribly broken and must
be fixed before it's allowed to reach the customers' hands.

I suppose you could interpret it as, "this unittest asserts that XYZ
holds in this part of the program; if it doesn't, it means something is
broken in the program logic". So it would be treated as a unittest
failure, which aborts the program.


T

-- 
Written on the window of a clothing store: No shirt, no shoes, no service.

Reply via email to