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

HadesMem v2 Work Has Started

I have finally returned to working on HadesMem, and at long last I am starting work on v2. This means I will hopefully be able to address some of the long-standing requests that require breaking changes to fix. Because of this I recommend you continue to use v1.6.0 until trunk is more stable. For the time being, trunk is going to be a bit of a minefield, but it will be worth it in the end. ;)

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

The missing blog Part #10b?

Recently I have been working on a project relating to keyboards and the translation of keyboard input to its associated character output. Basically, I want to cache all possible input combinations so I can look them up at runtime without having to call the ToUnicodeEx API with potentially 'tainted' state, which was causing problems with dead keys when I called it from a keyboard hook (or other similar mechanisms).

I have been working on this with the help of Michael Kaplan's blog and his amazingly detailed and helpful series Getting all you can out of a keyboard layout. So far I have just been porting the code to C++, one step in the series at a time, to gain a better understanding of how everything works. When I reached part 10a however I noticed that there seemed to be a missing part 10b. I raised this with Mr Kaplan on his blog and he has graciously agreed to write the final piece of the series.

No code from me yet (I do wish however to eventually post my port of the code to C++), but I wanted to give a shout-out to Mr Kaplan and encourage others to check out his awesome blog. If you're interested in i18n/l10n, languages, keyboards, etc you will probably find yourself going back and reading years worth of archives like I did.

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.

New Blog

As you may have noticed my site was down for some time and has now been moved to Blogger.

Long story short is that Wordpress is a fail that I don't have the patience to deal with, and I was also having trouble keeping away the occasional DDoS attacks I receive... So now it's Google's problem!

Hoping to get the old content imported when I get some spare time, but until then if you need anything desperately you can email me.

New content coming Soon™.