-----Original Message----- From: boost-bounces@lists.boost.org [mailto:boost-bounces@lists.boost.org] On Behalf Of Brad King
How does this effect the preprocessor library--aside from avoiding workarounds that GCC will report as ill-formed?
I don't think it does, but Dave Abrahams asked me to get your attention by mentioning the preprocessor library:
http://www.gccxml.org/pipermail/gccxml/2006-January/000698.html
I think my post on the gccxml list used slightly confusing wording and Dave thought this required only preprocessor parsing work-arounds. However, I wasn't sure if he was implying that you were the right person to make all the changes. Sorry for the confusion.
Well, the pp-lib presents the same interface on all supported preprocessors. If something cannot be ported (via workarounds) to a particular preprocessor, the mechanism simply isn't exposed as an interface, though the pp-lib implementation itself may use it internally. There are a few internal interfaces that are really useful that aren't presented as external interfaces. Some of those are used by users anyway. That's fine; I've recommended it many times along with the portability warning. However, there is nothing in the pp-lib that gcc's preprocessor can't handle--it is a very good preprocessor--with the exception of workarounds present for broken preprocessors. Some of those workarounds involve code that is either illegal or utilitizes undefined behavior. Explicitly catching __GCCXML__ should prevent the library from using any of these workarounds in the pp-lib itself. However, I obviously can't guarantee anything about what clients of the pp-lib might be doing for portability.
Changing that is simple enough for the preprocessor library. Already done--the configuration recognizes __GCCXML__ and defines BOOST_PP_CONFIG_FLAGS accordingly.
Great, thanks.
No problem. Regards, Paul Mensonides