The preprocessor macro PB_DEBUG_LEVEL is used to create conditionally compiled code in a manner somewhat similar to the standard DEBUG macro with the major difference being that it is not keyed strictly off of the debug vs. release compiler settings. It is often useful to compile back and forth between release and debug builds without affecting the message logging. In specific, we wanted a way to control the PB_DEFAULT_EXCLUDE and VALIDATE macros at the compilation level without using the DEBUG macro to do so. The PB_DEBUG_LEVEL macro allows for this and for similar control over your own code if you choose to use it. It has proven valuable in many development efforts in the past so we thought we would share its usage.

PB_DEBUG_LEVEL can obviously be defined and used in any manner the developer chooses but the following values and interpretations have historically proven to be a useful standard.


1 - Indicates a full functional release build. It is used to control things like performance tuning, using different message keys, etc. and to generally signify to code that the current build is an actual shipping version as opposed to simply being a release compiled version that may only be a non-debug test build or beta release. Note that this is the only level that affects the normal properties of the PB_DEFAULT_EXCLUDE and VALIDATE macros.

2 - Default value of PB_DEBUG_LEVEL for a release build. Used to indicate release-but-not-quite-ship builds to enable additional diagnostics.

3 - Default value of PB_DEBUG_LEVEL for a debug build. Used for same purpose as level 2 but with debug-enabled code.

4 - Indicates an ‘ultra’ debug build. It is interpreted the same as level 3 but may have different code/algorithms for testing or diagnostic purposes.


PB_DEBUG_LEVEL always defaults to a defined numeric value and to one of the two non-extreme levels of 2 or 3 rather than to the ‘ultra release’ level 1 or the ‘ultra debug’ level 4. This is done so that it effectively mirrors the DEBUG macro if not specifically overridden by the developer. The chief ramification of this is that the PB_DEFAULT_EXCLUDE and VALIDATE macros will not be affected without direct user intervention since they only change behavior in a level 1 build. A subtler feature is that since PB_DEBUG_LEVEL is always defined it may be used by the compiler as well as the preprocessor as in the following example:

    //If in test mode or at debug level 4 build then skip logon procedure.    
if (blInTestMode || PB_DEBUG_LEVEL == 4)
    blUserIsLoggedOn = TRUE;
    blUserIsLoggedOn = ShowLogonDialog();

or the tighter form:

blUserIsLoggedOn = (blInTestMode || PB_DEBUG_LEVEL == 4 || ShowLogonDialog());

which is in either case tighter than the form required if PB_DEBUG_LEVEL were not guaranteed to be defined:

    blUserIsLoggedOn = (PB_DEBUG_LEVEL == 4);

blUserIsLoggedOn = (blInTestMode || blUserIsLoggedOn || ShowLogonDialog());