Hi, I am using 4.6.2. When I ran my application (with mixed std flags) with Valgrind, Valgrind claimed that the member variable was uninitialized because at that moment, the address of that variable was off by 4 bytes. The type of that variable is boost::asio::detail::atomic_count. But I think that the type probably is irrelevant to this problem? On Tuesday, April 8, 2014 7:31 AM, Jonathan Wakely <jwakely.gcc@xxxxxxxxx> wrote: On 8 April 2014 09:06, Hei Chan wrote: > Hi, > > If I have a static library A that builds with default std with another header only library B, and then my program links library A and uses some classes in library B with -std=c++0x. Will this usage create any issue? > > I am running into an issue that one of the member variables in library B (boost ASIO to be precise) has a different memory address (only off by 4 bytes) over time. > > Any input is welcome. > > Thanks in advance. > > > Cheers, > Hei > P.S. I am using GCC 4.6.x on CentOS 6.5. With GCC 4.6.x, 4.7.2 or 4.8.x that should work OK. With GCC 4.7.0 or 4.7.1 there would be a problem if B uses std::list. You should be able to find why the offset of the ASIO type changed, it might not be due to a std::lib type.
