Boost.Preprocessor VARIADICS and VARIADICS_MSVC defined incorrectly under MSVC12

[iFreilicht]

In boost/preprocessor/config.hpp:line81 there is a check whether __EDG__ is defined or not. If it isn't, and the version of MSVC is higher than 1400, the macros BOOST_PP_VARIADICS and BOOST_PP_VARIADICS_MSVC are defined to be 1.

But, with VisualStudio 2013 and MSVC12, __EDG__ is defined to be 1, which of course breaks this part of the header, rendering variadic macros unusable.

The workaround is of course to define both BOOST_PP_VARIADICS and BOOST_PP_VARIADICS_MSVC before including any Boost.Preprocessor related files.

[Edward Diener]

I do not see in what situation EDG is defined in VC++12. Would you please supply a command line which generates that define ? Furthermore it is not listed in the documentation as a predefined macro.

[iFreilicht]

That is correct, it is not documented.

I'm sorry, I'm only talking about VisualStudio 2013 and VC++ 2013. From my knowledge it has the version number 12, that's why I called it that.

I have made a minimal case and it seems like __EDG__ is only defined under the IntelliSense compiler for what ever reason.

#if __EDG__
#error __EDG__ is defined 
#endif

This code will throw no error upon compilation, but IntelliSense shows it as getting reached and __EDG__ as being defined. Thus, compilation behaviour is not touched by this bug.

Also, after taking a closer look at preprocessor/config.hpp, there seems to be awareness for this.

In lines 34-39, it is first checked if __EDG__ is defined and then _MSC_VER. If they both are, the MSVC config flags are set as the result of BOOST_PP_CONFIG_FLAGS.

[Edward Diener]

VC++12 is the C++ version under Visual Studio 2013.

What does it mean when you say _EDG_ is only defined under the Intellisense compiler ? Is there a 'cl' compiler switch which you can show which defines _EDG_ ?

The definition of:

#        define BOOST_PP_VARIADICS_MSVC 1

is only made for the VC++ preprocessor when variadic macros are allowed. This means lots of workarounds for VC++ in the Boost PP code because VC++ does not have a standard C++ preprocessor. However if _EDG_ is defined Boost PP assumes a C++ standard conforming preprocessor and the VC++ workarounds are not used in that case. If Microsoft is defining _EDG_ in any situation I would like to understand the case because in terms of Boost PP this means a C++ conforming preprocessor and if that is not the case when _EDG_ is defined I have to find a workaround in Boost PP for that situation.

If _EDG_ is defined BOOST_PP_VARIADICS is set to 1 via the lines in config.h of:

#    elif !defined __cplusplus && __STDC_VERSION__ >= 199901L || __cplusplus >= 201103L
#        define BOOST_PP_VARIADICS 1

so BOOST_PP_VARIADICS will be defined if Microsoft is defining _EDG_ anywhere, but no workarounds for VC++'s broken preprocessor are then used.

[iFreilicht]

I mean it as I say it. To cite this article: ​http://blogs.msdn.com/b/vcblog/archive/2011/03/29/10146895.aspx

"The IntelliSense compiler is not the build compiler."

IntelliSense is "compiling" (with no file output, of course) code in the background to offer the red squiggly lines that point out programming mistakes before you actually compile the code with VC++.

And while it does that, the __EDG__ macro and some others, beginning with __EDG, are defined for whatever reason. Because the IntelliSense compiler is working very similarly to the VC++ compiler, it would of course need the workarounds for variadic macros to expand all the macros correctly, which are not used because __EDG__ is defined.

What that means is that certain macros of Boost.PP are underlined as programming errors by IntelliSense, but compile perfectly fine under VC++, as it doesn't define __EDG__. I have no idea why IntelliSense does it, it really makes no sense to me.

So this really isn't a showstopper or anything, but it is annoying.

What I propose as a fix is that you also check if __INTELLISENSE__ is defined, and base the definition of BOOST_PP_VARIADICS and BOOST_PP_VARIADICS_MSVC on that, too.

BTW: to prevent macros showing up like THIS, enclose them in backticks.

[Edward Diener]

I have updated the 'develop' branch of Boost PP in the current Boost on Github to fix this problem in general. If you could get this update and test against your source it would be appreciated. Alternatively I need some source to test your problems to see if the update I have made fixes them.

[Edward Diener]

This is fixed in the Boost 1.58 release.