assert(false)

[Jonathan M Davis]

On Thursday, June 20, 2013 15:45:14 Timothee Cour wrote:
> 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)?

If it _is_ known at compile time, then yes, but simply calling a function that 
_could_ be called during compile time won't result in it being checked at 
compile time.

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

It's only optimized away if the section of code that it's in is optimized 
away, and unreachable code is not necessarily optimized away. The compiler 
would have to determine that it's unreachable in order to do that, and it 
frequently can't do that. And assert(false) is turned into a HLT instruction 
with -release, so it never goes away because of -release, unlike other 
assertions.

- Jonathan M Davis