My main use case for writing this is to assemble my header only Boost libraries into a single "drop in and go" file. To that end it has a (still buggy) --passthru mode which passes through #define and #undef plus any #if logic which uses an undefined macro. I'm still working on pass through mode so expect showstopper bugs in that configuration, but as a straight highly standards conforming preprocessor it's ready for others to use and I welcome any feedback. There are a multitude of use cases, everything from running as a conforming preprocessor before invoking MSVC to compile right through to parsing, reflection and introspection of source code.
I did something very similar to this wave quite a few years back. We dubbed it partial preprocessing. It's still in use in Phoenix, iirc. We developed integrations for b2 and later on integrated it into our cmake build process for HPX. [snip] The advantage here is certainly to have a fully compliant C99 preprocessor at our disposal. Your usecase might differ slightly, but I am pretty confident that with a little change to our process, completely feasible. The only reason we got rid of wave 2 years ago was that we made variadic templates a prerequesite...
Interesting work of yours, and thanks for describing it. It is unfortunate you did not more widely publish its existence, else Facebook wouldn't have gone off and written Warp and I'm sure a raft of other people wouldn't have gone off and written their own hack solutions e.g. Phil Nash has a bespoke system in CATCH for example. Perhaps you should consider presenting at a major C++ conference on this work so a video search result pops up for those who come at this problem in the future? Your description also confirmed to me something which I suspected from studying the Wave sources before I started pcpp, which is that Wave is hard to customise in the way I was wanting. The technique of generating long lists of macros to not expand is one approach to solving this problem, however I believe one can take a more programmatic approach based on _source annotation_. I'm still testing the feasibility of my idea, and if it doesn't work I'll fall back onto the same approach you took, but if it does work then it'll be a much less brittle approach to take. I also have the very big advantage that I can embed Python script into my C++ headers to customise pcpp processing, not that I've leveraged that yet. Niall -- ned Productions Limited Consulting http://www.nedproductions.biz/ http://ie.linkedin.com/in/nialldouglas/