assert(false)

Timothee Cour thelastmammoth at gmail.com
Thu Jun 20 15:45:14 PDT 2013


A)
does assert(foo) where foo is an expression that cat be evaluated at
compile time (eg via CTFE etc) behave same as assert(true)/assert(false)?


B)

It is usually "bad practice" to keep an assert in release
> ("assert(false)"), because the code should already have been checked, and
> you shouldn't pay for the check in release.
> BUT: Since the code is theoretically unreachable, there is no real world
> penalty to the check anyway, so you might put it in anyways, on the off
> chance it saves your but (IMO).


What do you mean by 'you shouldn't pay for the check in release' ?
If the boolean argument is known at compile time, there is no check, so no
overhead right? (ie compiler should optimize away)





On Thu, Jun 20, 2013 at 2:25 PM, Jonathan M Davis <jmdavisProg at gmx.com>wrote:

> On Thursday, June 20, 2013 22:21:28 Joseph Rushton Wakeling wrote:
> > In my case it was a bunch of if/else where the program should return from
> > one of the blocks. I saw comparable cases in RandomCover with an
> > assert(false) at the very end of the function, so thought I'd better
> tweak
> > my code accordingly.
>
> Putting it at the end of the function is unnecessary. The compiler already
> does that for you.
>
> - Jonathan M Davis
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.puremagic.com/pipermail/digitalmars-d-learn/attachments/20130620/5a4e0ed9/attachment-0001.html>


More information about the Digitalmars-d-learn mailing list