On Sunday 17 August 2014 13:56:39 Edward Diener wrote:
Unfortunately the second situation involving warnings, where clang warns about:
warning: empty macro arguments are a C99 feature [-Wc99-extensions]
coming from what I only see as a specific place in Boost PP in variadic/elem.hpp is not conducive to the same technique. In other words surrounding that one macro with:
# ifdef __clang__ # pragma clang diagnostic push # pragma clang diagnostic ignored "-Wc99-extensions" # endif
#define BOOST_PP_VARIADIC_ELEM(n, ...) BOOST_PP_CAT(BOOST_PP_VARIADIC_ELEM_, n)(__VA_ARGS__,)
# ifdef __clang__ # pragma clang diagnostic pop # endif
does not eliminate the warning at all ( I have reported this on the clang developers mailing list ). And since that macro is heavily used in Boost PP this warning occurs quite often when compiling Boost library code using Boost PP wih clang.
Are the warnings emitted upon the macro expansion? If so you could try embedding _Pragma into the macro.
The only other intrusive Boost PP solution to this problem is to treat clang like gcc as far as Boost PP variadic macro code is concerned: if the end-user compiles with one of the 'std=' dialects which explicitly supports variadic macros, such as 'std=c99', 'std=c++0x, 'std=c++11', then variadic macros are turned on in Boost PP for clang, else they are turned off. Do realize that both gcc and clang support variadic macros even when one of the 'std=' dialects are not chosen, and that in fact clang has always supported variadic macros. Also changing Boost PP support for clang and variadic macros would be a regression from the way it is now where it is always supported.
IMHO, if nothing helps then it is ok to enable variadic macros only when supported by the standard. That is the only condition we can require from compilers. Other cases are extension, which may not be usable and it's ok if we don't use it when it brings caveats like this.