c++ - Is there any reason not to wrap assert() in a macro that resolves to __builtin_unreachable() in gcc? -


context: in answer, learned gcc's __builtin_unreachable() can have surprisingly impactful performance implications, seems following:

if(condition) __builtin_unreachable(); 

is being entirely stripped, , used optimization hint long condition can guaranteed not have side effect.

so immediate reaction should create following macro, , use absolutely everywhere use assert(), since side-effect inducing code inside assert() major bug in first place:

// todo: add handling of other compilers appropriate. #if defined(__gnuc__) && defined(ndebug)   #define my_assert(condition) \     if(!(condition)) __builtin_unreachable() #else    #define my_assert(condition) assert(condition) #endif 

from standards perspective, create split in functionality between normal , ndebug builds, make argument excludes macro being standard behavior of assert(). however, since code functionally dead in water in case of assertion failures regardless, it's equivalent behavioral standpoint.

so question is: can think of reason not (appart asserts involve lot of indirections)?

before ask, yes, i've checked gcc's behavior void cast assertion away in ndebug builds.

yes, there reason not use it. people use following defensive code practice combines assert , exception ( assert(x>0); if (!(x<0)) throw std::logic_error("..") ) - see answer:

test cases , assertion statements

your macro silently breaks exception-part release builds.


Comments

Popular posts from this blog

Sort a complex associative array in PHP -

vb.net - How to ignore if a cell is empty nothing -

recursion - Can every recursive algorithm be improved with dynamic programming? -