[boost::shared_ptr] Easy to violate the One Definition Rule / C++11 / Check für standard used to compile Boost
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
On 15 Jan 2014 at 15:45, beet wrote:
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).
That happens all over the place always in any C++11 build mixed with C++03 binaries. It's normally not an issue because the library author will have taken care to ensure ABI compatibility irrespective of how their code is built. Yes it is a violation of the C++ standard, but that's also normally not an issue. There are very few - if any - real world C++ codebases of any size which are fully valid and legal programs according to the standard. I personally can't think of one I've ever seen, not ever.
Hence: Is there any way I can check (e.g. through some #define provided by Boost) what C++ standard it has been compiled with ?
Boost provides a series of C++11 header check macros as various C++11 compilers provide varying amounts of C++11. You could encode these into linker symbols, and use those as fingerprints. Boost does not do this currently to my knowledge. I once asked GCC to add a magic symbol fingerprint to all ELF binaries to say what C++ version they were built with. I figured it would be extremely useful to know for debugging. I was roundly told no, period. On MSVC, things are much easier as the version of MSVCRT is iterated every MSVC release. That lets you very easily know what compiler built what library by examining what MSVCRT version it uses. Niall -- Currently unemployed and looking for work in Ireland. Work Portfolio: http://careers.stackoverflow.com/nialldouglas/
participants (2)
-
beet -
Niall Douglas