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@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