Commit ea5b48a

ms.date: "09/03/2019"

You can detect which preprocessor is in use at compile time. Check the value of the predefined macro [\_MSVC\_TRADITIONAL](../../preprocessor/predefined-macros.md) to tell if the traditional preprocessor is in use. This macro is set unconditionally by versions of the compiler that support it, independent of which preprocessor is invoked. Its value is 1 for the traditional preprocessor. It's 0 for the conformant experimental preprocessor:

#if defined(_MSVC_TRADITIONAL) && _MSVC_TRADITIONAL

// Logic using the traditional preprocessor

#else

// Logic using cross-platform compatible preprocessor

#endif

Here are some of the more common breaking changes found when preprocessor conformance mode is enabled:

The traditional preprocessor uses character buffers instead of preprocessor tokens. That allows some unusual behavior, such as this preprocessor comment trick, which doesn't work under the conforming preprocessor:

#if DISAPPEAR

#define DISAPPEARING_TYPE /##/

#else

#define DISAPPEARING_TYPE int

#endif

DISAPPEARING_TYPE myVal;

The traditional preprocessor incorrectly combines a string prefix to the result of the [stringizing operator (#)](../../preprocessor/stringizing-operator-hash.md):

#define DEBUG_INFO(val) L"debug prefix:" L#val

const wchar_t *info = DEBUG_INFO(hello world);

The `L` prefix is unnecessary here, because the adjacent string literals get combined after macro expansion anyway. The backward compatible fix is to change the definition to:

#define DEBUG_INFO(val) L"debug prefix:" #val

This issue is also found in convenience macros that 'stringize' the argument to a wide string literal:

#define STRING(str) L#str

#define STRING1(str) L""#str

#define WIDE(str) L##str

#define STRING2(str) WIDE(#str)

#define STRING3(str) L## #str

#### Comma elision in variadic macros

Consider the following example:

```cpp

void func(int, int = 2, int = 3);

// This macro replacement list has a comma followed by __VA_ARGS__

#define FUNC(a, ...) func(a, __VA_ARGS__)

int main()

{

// The following macro is replaced with:

// func(10,20,30)

FUNC(10, 20, 30);

// A conforming preprocessor replaces the following macro with:

// func(1, );

// which results in a syntax error.

FUNC(1, );

}

In the upcoming C++2a standard, this issue has been addressed by adding `__VA_OPT__`, which isn't implemented yet.

In the traditional preprocessor, if a macro forwards one of its arguments to another dependent macro, then the argument doesn't get "unpacked" when it's substituted. Usually this optimization goes unnoticed, but it can lead to unusual behavior:

#define TWO_STRINGS( first, ... ) #first, #__VA_ARGS__

#define A( ... ) TWO_STRINGS(__VA_ARGS__)

const char* c[2] = { A(1, 2) };

// Conformant preprocessor results:

// const char c[2] = { "1", "2" };

// Traditional preprocessor results, all arguments are in the first string:

// const char c[2] = { "1, 2", };

To see what is going on in this example, we break down the expansion starting with `DO_THING`:

`DO_THING(1, "World")` ->

Second, CAT is expanded:

`CAT(IMPL, 1)` -> `IMPL ## 1` -> `IMPL1`

Which puts the tokens into this state:

The preprocessor finds the function-like macro identifier `IMPL1`, but it's not followed by a "(", so it's not considered a function-like macro invocation. It moves on to the following tokens and finds the function-like macro `ECHO` invoked:

`ECHO(("Hello", "World"))` -> `("Hello", "World")`

`IMPL1` is never considered again for expansion, so the full result of the expansions is:

The macro can be modified to behave the same way under both the experimental preprocessor and the traditional preprocessor. The solution is to add another layer of indirection:

#define CAT(a,b) a##b

#define ECHO(...) __VA_ARGS__

#define IMPL1(prefix,value) do_thing_one( prefix, value)

#define IMPL2(prefix,value) do_thing_two( prefix, value)

#define CALL(macroName, args) macroName args

#define DO_THING_FIXED(a,b) CALL( CAT(IMPL, a), ECHO(( "Hello",b)))

DO_THING_FIXED(1, "World");

The experimental preprocessor isn't complete yet, and some preprocessor directive logic still falls back to the traditional behavior. Here is a partial list of incomplete features:

- Support for `_Pragma`

- C++20 features

- Additional diagnostic improvements

- Switches to control the output under /E and /P

- Boost blocking bug: Logical operators in preprocessor constant expressions aren't fully implemented in the new preprocessor. On some `#if` directives, the new preprocessor can fall back to the traditional preprocessor. The effect is only noticeable when macros that are incompatible with the traditional preprocessor get expanded, which can happen when building Boost preprocessor slots.