Structure size when compiling with and without -std=c++11
Hi,
I would like to share my experience with boost when combining with c++11. I
hope it might help someone.
Suppose a simple program:
#include
On 31.07.2015 21:25, Miloslav Marik wrote:
Hi,
I would like to share my experience with boost when combining with c++11. I hope it might help someone.
Suppose a simple program:
#include
#include <iostream> using boost::asio::detail::atomic_count;
struct Test { // Whether the task has been interrupted. bool task_interrupted_;
// The count of unfinished work. atomic_count outstanding_work_; };
int main () { std::cout << "Size is " << sizeof(Test) << std::endl; return 0; } And here is the story:
$ /opt/gcc-4.8.4/bin/g++ -std=c++11 -I /opt/boost-1.58.0/include/ -L /opt/boost-1.58.0/lib -lboost_system b.cpp $ ./a.out Size is 16 $ /opt/gcc-4.8.4/bin/g++ -I /opt/boost-1.58.0/include/ -L /opt/boost-1.58.0/lib -lboost_system b.cpp $ ./a.out Size is 8
It means that c++11 program cannot be linked with boost libraries compiled without "-std=c++11" option. It was asio in my case and the program was linked with libboost_log.so.1.58.0.
This is known: https://svn.boost.org/trac/boost/ticket/9207 Using BOOST_ASIO_DISABLE_STD_ATOMIC helps and would yield size 8. But the ticket is wrong, the problem exists with clang, too. On OS/X, at least. Cheers, Leon
On 1/08/2015 07:25, Miloslav Marik wrote:
It means that c++11 program cannot be linked with boost libraries compiled without "-std=c++11" option. It was asio in my case and the program was linked with libboost_log.so.1.58.0.
In general it is a Really Bad Idea™ to link object files created with different ABI standards (including C++ standard, but there are also other settings that affect this), or that use a different libc/STL. Sometimes you can get away with linking files created by different compilers (in particular I think GCC and Clang are designed to be interoperable, provided you're using the same C++ ABI and libc settings), but in general you should try to avoid that too. If you're using DLLs/SOs and the API is designed *really* carefully, then you may at times be able to interoperate with different compilers/libc, but this is quite tricky unless you stick with a pure C API (since the C ABI is simpler and more stable).
participants (3)
-
Gavin Lambert
-
Leon Mlakar
-
Miloslav Marik