A)<div>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)?</div><div><br></div><div><br class="Apple-interchange-newline">B)</div><div>
<br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex">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.<br>
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).</blockquote><div><div><br></div><div>What do you mean by 'you shouldn't pay for the check in release' ? </div>
<div>If the boolean argument is known at compile time, there is no check, so no overhead right? (ie compiler should optimize away)</div><div><br></div><div><br></div><div><br></div><div><br></div><br><div class="gmail_quote">
On Thu, Jun 20, 2013 at 2:25 PM, Jonathan M Davis <span dir="ltr"><<a href="mailto:jmdavisProg@gmx.com" target="_blank">jmdavisProg@gmx.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<div class="im">On Thursday, June 20, 2013 22:21:28 Joseph Rushton Wakeling wrote:<br>
> In my case it was a bunch of if/else where the program should return from<br>
> one of the blocks. I saw comparable cases in RandomCover with an<br>
> assert(false) at the very end of the function, so thought I'd better tweak<br>
> my code accordingly.<br>
<br>
</div>Putting it at the end of the function is unnecessary. The compiler already<br>
does that for you.<br>
<span class="HOEnZb"><font color="#888888"><br>
- Jonathan M Davis<br>
</font></span></blockquote></div><br></div>