HadesMem and MinGW-w64

In an earlier post, I mentioned that HadesMem v2 now works under GCC and Clang (both of which use the MinGW-w64 runtime on Windows). This is still true, but the question now is, for how long? I have been trying recently to get GCC and Clang to play nice on a personal project of mine which uses a lot of COM and ATL code, but it seems to be a lost cause. There are entire header files which are missing from MinGW-w64, and a lot of COM APIs which are missing from the existing header files.

Up until now, supporting GCC and Clang in HadesMem has been a bit of a maintenance headache, but nothing that couldn't be overcome with some simple workarounds and #ifdefs. Now however, it seems that I need to pick between having full access to the Windows APIs, or having support for MinGW-w64 (I simply don't have the time nor the motivation to add support for all these APIs to MinGW). For the lower level components it seems that MinGW-w64 contains everything I need, but problems quickly arise when trying to write higher-level code (using the Shell COM interfaces, ATL, WTL, etc), which is of interest to me for HadesMem because I'd like to write a couple of basic GUI tools on top of the library.

So, I guess the point of this whole post is to find out whether there is actually any interest from library users in support for compilers other than MSVC. If there is please let me know, using whatever method suits you best (the comments, email, etc). I haven't made up my mind yet, but it seems that the drawbacks are very quickly piling up against the benefits...

EDIT:

It is of course possible I could simply continue to support all compilers for the library portion, then make the tools written on top of it MSVC-only, but then that becomes a pain when maintaining the build system. The other alternative is to simply 'suck it up' and rewrite all the code (where possible) to support MinGW, and where it isn't to actually fix/extend MinGW, however I'm not sure I really want to put that much work into a platform I don't really use other than to make sure my code is as portable as possible.

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 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.