On 3/7/2017 11:16 AM, Niall Douglas via Boost wrote:
pcpp by default acts as a straight preprocessor, but it can also be told to pass through #if logic it can't fully execute due to unknowns, or partially execute #if logic. It can be told to pass through #define and #undef but also execute them (or not) on a per-macro basis. It would be easy enough to tell it to not execute any preprocessing commands except #include and include guards for example.
The practical problem with this is that source files with preprocessor directives often depend on the compiler being used, with its predefined macros, to generate the correct output.
Do note pcpp can pass through #if logic which uses undefined macros. So as compiler specific macros will be undefined, all #if logic relating to them passes through. The output is therefore still portable across compilers.
Passing through all #if logic cannot be right ! #if SOME_PREDEFINED_MACRO >= some_value some_code #endif #if SOME_PREDEFINED_MACRO < some_value some_other_code #endif If both "some_code" and "some_other_code" are passed through I doubt the output will be correct. Because of quirks in compiler preprocessors. especially VC++, a great deal of macro logic in Boost PP and Boost VMD is based in identifying compilers and their levels of C/C++ standards compliance, which is done by compiler predefined macros. I would imagine that this could be extended to others writing their own macros, whether they use Boost PP/VMD or not. Of course various cross-platform header files also depend on such information. I am not trying to minimize your effort in any way in writing pcpp. I am just saying that to use it as the preprocessor front-end for various compilers is more complicated than I believe you think. Unless pcpp can create the same predefined macros which the backend compiler's preprocessor creates I doubt if the output can be reliable in many situations.
Don't get me wrong, there is still a small amount of hand tuning involved, so a human does need to grok the output and make sure it's coming out okay and if not, add another command line argument to force things. But so far, at least for Outcome, it is coming out pretty much right first time (though this entirely could be how I write my preprocessor, and Outcome being all C++ 14 doesn't support broken compilers except for MSVC. So my use case is much simpler than most).