###  | # Boost.Preprocessor ## Known problems with specific compilers

Some compilers have buggy or limited preprocessors. This page explains known problems with specific compilers.

## Contents

- Metrowerks Codewarrior 7.0
- Comeau C/C++ 4.2.45.2 for Windows

### Metrowerks Codewarrior 7.0

Metrowerks Codewarrior 7.0 has a bug in preprocessor (to be more concrete, in function-like macro replacement mechanism) that restricts usage of the library to only very simple cases, at least if you don't write code that specifically address this issue; for example, the above NUMBERED_EXPRESSION example doesn't compile on CW 7.0. Below is a simple test case that reproduces the bug:

>     #define IDENTITY_MACRO(x) IDENTITY_MACRO_BODY(x)
>     #define IDENTITY_MACRO_BODY(x) x
>     #define COMMA_TOKEN() ,
>     int a IDENTITY_MACRO(COMMA_TOKEN)() b; // this works
>     int c IDENTITY_MACRO(IDENTITY_MACRO(COMMA_TOKEN))() d; // this doesn't

Basically, what's happening here is that function-like COMMA_TOKEN macro gets expanded _inside_ of the nested IDENTITY_MACRO call - even although it's NOT followed by a '(' as the next preprocessing token - which is a clearly an incorrect behavior (see 16.3 [cpp.replace] para 9 for the detailed description of the function-like macro replacement process). I've submitted a bug report, but they haven't confirmed it yet.

So, this is not a problem of the library, but probably something that needs to be mentioned in the documentation, may be with some examples of how to workaround the issue. Just to show one possible way around the problem, here is a NUMBERED_EXPRESSION macro that does work on MWCW:

>     #define NUMBERED_EXPRESSION(n, x) \
>         BOOST_PP_CAT(BOOST_, \
>         BOOST_PP_IF( \
>           n \
>         , PREPROCESSOR_IDENTITY(x##n) \
>         , PREPROCESSOR_EMPTY \
>         ))() \
>     /**/

Reported by Aleksey Gurtovoy

### Comeau C/C++ 4.2.45.2 for Windows

It appears that their algorithm of macro call invocation is quite far from ideal, because for the following code fragment (which is a part of preprocessor_test.cpp), the linear increasing of IS_FUNCTION_HELPER_TEST_MAX value leads to not even quadratic, but something like exponential increasing of compilation time! (see the timing data below). This behavior may or may not be problematic for you, depending on how intense is your usage of the library.

>     #ifndef IS_FUNCTION_HELPER_TEST_MAX
>     #define IS_FUNCTION_HELPER_TEST_MAX 40
>     #endif

>     typedef char yes_type;

>     #define IS_FUNCTION_HELPER(I,A)\
>       template\
>       <BOOST_PP_ENUM_PARAMS(BOOST_PP_INC(I),class P)>\
>       yes_type is_function_helper(\
>         P0 (*)(BOOST_PP_ENUM_SHIFTED_PARAMS(BOOST_PP_INC(I),P)));

>     BOOST_PP_REPEAT_2ND(BOOST_PP_INC(IS_FUNCTION_HELPER_TEST_MAX),IS_FUNCTION_HELPER,A)

>     #undef IS_FUNCTION_HELPER

#### Timing data:

| Comeau C/C++ 4.2.45.2 | Microsoft Visual C++ 6.0 SP5
--- | --- | ---
10 parameters | < 1 sec | < 1 sec
20 parameters | ~ 2 sec | < 1 sec
30 parameters | ~ 15 sec | < 1 sec
40 parameters | ~ 50 sec | < 1 sec

Reported by Aleksey Gurtovoy

Revised

© Copyright Housemarque Oy 2002

Permission to copy, use, modify, sell and distribute this document is granted provided this copyright notice appears in all copies. This document is provided "as is" without express or implied warranty, and with no claim as to its suitability for any purpose.