On 10/27/2016 4:35 PM, Andrey Semashev wrote:

On Thu, Oct 27, 2016 at 11:11 PM, Edward Diener wrote:

...

I need some guidance from Boost developers in general.

A PR has been issued for Boost PP which only affects Intel C++ 17 on up in Windows. I can ascertain that only this compiler in Windows is affectd by the PR. Needless to say I do not test this personally because it costs a decent amount of money to buy a license. Intel does graciously offer free licenses for Intel C++ on Linux for Boost developers and I have used it to test the compiler under Linux. Also there are no regression tests for Intel C++ on Windows in the 'develop' or 'master' regression test matrices.

While the person who issued the PR ascertains that it fixes problems for Boost libraries he uses with Intel C++ 17 on Windows the nature of the PR is drastic enough that it could easily break other libraries if the changes in the PR does not correspond to Intel C++ preprocessing in all cases. So my quandary is what to do about the PR.

The PR is at https://github.com/boostorg/preprocessor/pull/9#issuecomment-256741882. It is another one of these cases, like clang targeting VC++, where a compiler implementation on Windows wants to emulate the non-standard VC++ preprocessor but can't quite get it right ( as if emulating a broken preprocessor should ever be right ).

Thoughts ? Ideas ? Suggestions ?

Assuming you don't mind adding more workarounds to the library and thus complicating it, and you understand what the PR does, I think it's pretty safe to trust the submitter and merge it. You will see if it affects other compilers (the ones in the test matrix and listed as the officially supported), and hopefully this will also fix the compiler we don't test.

I know it won't affect other compilers as I can easily tell that from the PR. I am just worried it will break for users of Intel C++ 17 on Windows using other Boost libraries. Furthermore if it does break anything else in that environment I am not going to spend any time trying to figure out what to do other than to back out the fix. I have already said that there is no way I will personally play around with a compiler trying to emulate the broken VC++ preprocessor, even if I did have access to it, which I do not.

If it doesn't (or if it breaks something on the unsupported compiler), that's not such a big deal. You will likely hear about it anyway.

That's fine and my reaction will be to back out the PR unless someone else wants to submit another one to "fix" the problem.

On 10/27/2016 5:38 PM, Peter Dimov wrote:

Edward Diener wrote:

...

I know it won't affect other compilers as I can easily tell that from the PR. I am just worried it will break for users of Intel C++ 17 on Windows using other Boost libraries.

In such a situation I generally trust the submitter because he has vested interest in Boost working on the specific compiler/platform.

Thanks, Peter. I value your opinion.