Boost Addressof Warning/Error under Intel C++ 13

Another quick post to provide a patch which fixes a warning in Boost.Utility/Addressof. This warning occurs under Intel C++ 13 (and probably other versions) when compiling at the highest warning level. Unlike other warnings though, it apparently cannot be disabled with #pragma directives, so if you compile with warnings as errors it results in an error which you cannot disable.

The root of the problem seems to be that the compiler thinks an rvalue is being passed to a function taking a non-const reference, however in this case it is a false positive (the rvalue has an implicit conversion operator which returns a reference to the underlying lvalue which it is wrapping). I have worked around it by turning the wrapper into an lvalue and passing that instead.

Boost.Test Warning under Intel C++ 13 Beta Update 2

Just a quick post to provide a patch to fix a warning that I was unable to silence with pragmas when using Boost.Test under ICC v13 Beta Update 2 (does not happen on all uses of Boost.Test, I'm unsure of the exact trigger).

Boost.Signals Compile Error under VC11 Developer Preview

To keep with the theme of providing patches for issues in Boost I have discovered which are yet to be fixed upstream, I have one final patch which addresses a compilation error in Boost.Signals under VC11.

This patch is extremely trivial, as there is already MSVC specific workaround code in place for this particular error, however it only covers up to VC10. The patch simply bumps the version number to that of VC11.

Boost.Interprocess under GCC via MinGW-w64 Pedantic Warnings

When compiling projects consuming Boost.Interprocess for Windows using GCC via MinGW-w64, if you have both pedantic warnings and warnings as errors enabled, then a warning is generated in Boost.Interprocess that is impossible to disable via the GCC diagnostic pragmas.

I am providing a quick and dirty patch to work around that. Be warned however that the header in question is a mess, and full of 'suspect' code. This patch does nothing to address that, it simply works around the warning in the simplest manner I could see (another alternative would be to perform the cast responsible for the error with a union instead of a reinterpret_cast, however that just adds to the standards conformance violations).

Boost with Intel C++ (12.1.3.300) on Windows

Intel's standard library headers are disgusting and are committing the cardinal sin of defining macros which may interfere with user code (which in this case they have).

The problem is simple to repro:

#include <atomic>
#include <boost/shared_ptr.hpp>
int main() { }

Or:

#include <atomic>
#include <boost/thread.hpp>
int main() { }

This issue has been reported previously to Intel, but remains even in the latest version of the compiler (created and released well after the bug report):

I am using two patches locally, one for Boost.SmartPtr, and one for Boost.Thread.

The patches have been sent to the Boost developer mailing list, but I have not yet received a response. They are also on the Boost bug tracker as #6842 and #6843. They're pretty disgusting themselves, but at least compiling code using Boost on Intel C++ works now. At the very least they probably require a bit of extra wrapping to detect affected versions and configurations (e.g. v12 with C++0x mode).

I still get the feeling though that there is a better workaround, so if anyone has any ideas I'd love to hear them.