Boost's quality of implementation is the same as libstdc++ or libc++, you can get multiple instantiations in certain circumstances and those can have differing addresses.
The various error categories are implemented (for header-only libraries) as inlined Meyer singletons. Does that mean that we have a general problem with such singletons?
The short answer is yes, the error category comparison operators are unreliable on all major STLs apart from Dinkumware's and in Boost. The longer answer is that the hack of strcmp()ing the name() works surprisingly well in practice, and it might be wise if Boost's error categories implemented that, followed by libstdc++ and libc++. I expect after Charley Bay bangs the drum on this stuff at C++ Now followed very shortly thereafter by me banging the drum at ACCU that we might draw some attention to this problem by the STL maintainers. The only one who really gets the problem is Stephan, but his solution for Dinkumware does bring in an atomic fence which he himself admits is a bit heavy. It certainly causes a lot of code bloat when using Outcome with the Dinkumware STL, as every possible error code construction point requires an atomic fence. I've done some remedial evil hackery in Outcome to bypass Stephan's atomic fence some of the time on VS. It's the best I can do given the constraints. Niall -- ned Productions Limited Consulting http://www.nedproductions.biz/ http://ie.linkedin.com/in/nialldouglas/