[Boost-users] [boost::shared_ptr] Easy to violate the One Definition Rule / C++11 / Check für standard used to compile Boost

Subject: [Boost-users] [boost::shared_ptr] Easy to violate the One Definition Rule / C++11 / Check für standard used to compile Boost
From: beet (r.berlich_at_[hidden])
Date: 2014-01-15 09:45:36

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