public inbox for gcc-help@gcc.gnu.org
 help / color / mirror / Atom feed
* Expected Behavior in Mixing -std=c++0x and default std?
@ 2014-04-08  8:06 Hei Chan
  2014-04-08 14:31 ` Jonathan Wakely
  0 siblings, 1 reply; 3+ messages in thread
From: Hei Chan @ 2014-04-08  8:06 UTC (permalink / raw)
  To: gcc-help

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.

^ permalink raw reply	[flat|nested] 3+ messages in thread

* Re: Expected Behavior in Mixing -std=c++0x and default std?
  2014-04-08  8:06 Expected Behavior in Mixing -std=c++0x and default std? Hei Chan
@ 2014-04-08 14:31 ` Jonathan Wakely
  2014-04-08 22:44   ` Hei Chan
  0 siblings, 1 reply; 3+ messages in thread
From: Jonathan Wakely @ 2014-04-08 14:31 UTC (permalink / raw)
  To: Hei Chan; +Cc: gcc-help

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.

^ permalink raw reply	[flat|nested] 3+ messages in thread

* Re: Expected Behavior in Mixing -std=c++0x and default std?
  2014-04-08 14:31 ` Jonathan Wakely
@ 2014-04-08 22:44   ` Hei Chan
  0 siblings, 0 replies; 3+ messages in thread
From: Hei Chan @ 2014-04-08 22:44 UTC (permalink / raw)
  To: Jonathan Wakely; +Cc: gcc-help

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@gmail.com> 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.

^ permalink raw reply	[flat|nested] 3+ messages in thread

end of thread, other threads:[~2014-04-08 22:44 UTC | newest]

Thread overview: 3+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2014-04-08  8:06 Expected Behavior in Mixing -std=c++0x and default std? Hei Chan
2014-04-08 14:31 ` Jonathan Wakely
2014-04-08 22:44   ` Hei Chan

This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).