Boost logo

Boost Users :

Subject: Re: [Boost-users] [boost::shared_ptr] Easy to violate the One Definition Rule / C++11 / Check für standard used to compile Boo
From: Niall Douglas (s_sourceforge_at_[hidden])
Date: 2014-01-15 12:03:09


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/



Boost-users list run by williamkempf at hotmail.com, kalb at libertysoft.com, bjorn.karlsson at readsoft.com, gregod at cs.rpi.edu, wekempf at cox.net