Hi there, from what I can see, boost::shared_ptr has a different definition, depending on whether Boost is compiled in C++98 oder C++11 mode. For example, in C++11-mode, shared_ptr has a move-constructor. By default, however, Boost seems to be compiled in C++98 mode, even with a compiler like gcc 4.8 (Ubuntu 13.10 / 64 bit / Boost 1.55), that is perfectly capable of compiling in C++11 mode. So, while boost::shared_ptr is header-only, all Boost libraries that use boost::shared_ptr will assume the C++98 version. The build-environment of one of my applications checks the compiler (currently gcc and CLang) and, depending on the version, activates C++11 support, so that I can use some C++11-checks (such as override), that can easily be #defined away for C++98 . So what may happen here is that my main application uses a different boost::shared_ptr than the Boost libraries I want to link with. To me this seems to violate the one-definition rule (and may happen with other Boost libraries as well). Indeed I'm seeing some strange errors, where "if(!p) {raise_error();}" triggers for a shared_ptr<derived_class> p, but I can still access member functions of a base_class that derived_class is derived from. Now, while I'm not yet sure that the above is the cause of this problem, I'd like to make sure that my build system chooses the appropriate C++ standard for compilation. Hence: Is there any way I can check (e.g. through some #define provided by Boost) what C++ standard it has been compiled with ? Thanks and Best Regards, Beet