Le 12/07/12 12:01, Andrey Semashev a écrit :
On Thursday 12 July 2012 10:21:12 Sebastian Redl wrote:
This is a case where I compiled boost with a different version of g++ (or perhaps without c++0x support??) resulting in binary incompatibility when the BOOST_SCOPED_ENUM is used in the header of a compiled library.
This seems like a bad API choice as it requires all programs that use boost::filesystem::copy_file to use the same version of G++ with the same compile options. In this case, the library should (in theory) implement both the scoped enum and unscoped enum implementation so that I can mix and match C++03 code with C++0x code without having two different versions of boost::filesystem. You cannot safely mix and match C++03 and C++11 code with GCC no matter what libraries you use. The standard library itself breaks binary compatibility between the two versions. Boost builds on the standard
On 11.07.2012 20:05, Daniel Larimer wrote: library. So no change in Filesystem is going to rescue binary compatibility for you. But you can build and link both C++03 and C++11 programs against libstdc++, can't you? So it must either contain both ABIs or have some compatibility layer. Why is it not possible to use both ABIs then?
BTW, I filed a ticket for this problem earlier:
Hi, This is a severe issue that Boost.Thread should share since the introduction of scoped enums. Is there a way to solve it, other than using always the emulation? Is this kind of errors limited to scoped enums or there are other C++11 emulated Boost constructions that have different ABI with c++03 and C++11? I'm thinking to constexpr, noexcept, ... Best, Vicente