HadesMem v2 Compiler Support

So, it's been a while since I've started work on HadesMem v2 and I wanted to give a status update. So far everything is going relatively smoothly... I'm still working on rewriting and reintegrating all the v1 components (fixing bugs and adding minor features along the way), however one of the biggest changes made so far is that HadesMem now compiles and runs (examples and tests) on every major C++ compiler for Windows. This means that HadesMem now works under the latest versions of MSVC (11), Intel C++ (13), GCC (4.7), and even Clang (3.1)! Please note that support for compilers other than MSVC is still considered experimental and subject to change, but I'm quite happy with the state of things now, so I believe I will be able to maintain compatibility across all compilers from this point onward (however when v2 is finally 'finished' the required compiler versions will probably be newer than those listed here).

More information on other new developments to come Soon.

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

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.