08-23-2013 08:54 AM
I did not do a systematic study and thus other macros may show the same behavior:
assert, for example, gives the compiler warning that it will be never executed
the same is true for DefineThreadSafeVar
Solved! Go to Solution.
08-23-2013 03:54 PM - edited 08-23-2013 03:56 PM
For Assert, this warning is ironically caused by exactly the behavior the macro was designed for. The Assert macro uses a ternary operator to determine if it should trigger an error or continue execution. Obviously, with a ternary operator, one of the operations is going to be executed while the other will not. If the compiler is able to determine that your assert condition will always have the same outcome (e.g. 0 == 0), then you will get this warning.
For DefineThreadSafeVar, this is occurring because DefineThreadSafeVar is really the same as calling DefineThreadSafeScalarVar with the maxGetPointerNesting parameter set to -1. In this case, the new warning is accurately reflecting the fact that a conditional statement inside a macro called by DefineThreadSafeScalarVar checks if maxGetPointerNesting is >= 0 (which it never will be). There are actually two warnings that code will not be executed: one for the line of code inside this conditional, and one for the second half of the conditional. This conditional is inside the CheckThreadSafeVarNestedLockCount macro which is used by several of the thread safe variable macros and is thus generalized. You can take a look at all of these macros in utility.h. This warning can be safely ignored, or you can get rid of it by using DefineThreadSafeScalarVar with a really large maxGetPointerNesting parameter. I have filed bug report 423739 for this issue.
08-24-2013 01:52 AM
Thank you for the detailed explanation!