Subject: Re: [boost] [preprocessing] Feedback requested on a C99 preprocessor written in pure universal Python
From: Edward Diener (eldiener_at_[hidden])
Date: 2017-03-07 17:03:36
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
Passing through all #if logic cannot be right !
#if SOME_PREDEFINED_MACRO >= some_value
#if SOME_PREDEFINED_MACRO < some_value
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
> 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).