On 10/10/2011 08:07 PM, Gabriel Dos Reis wrote:
PODness has changed from C++98.
Class layout in the ABI still uses the C++98 definition of POD.
Jason
On 10/10/2011 08:07 PM, Gabriel Dos Reis wrote:
PODness has changed from C++98.
Jason Merrill wrote:
Class layout in the ABI still uses the C++98 definition of POD.
But does this actually matter? If I understand correctly, more classes are POD
under the C++11
rules than the C++98 rules, but
On 01/05/2012 01:38 PM, Joe Buck wrote:
Class layout in the ABI still uses the C++98 definition of POD.
But does this actually matter?
Yes, since PODness affects the use of tail padding. But it isn't a
source of ABI incompatibility since POD for the purpose of layout
isn't changing.
On Mon, Oct 10, 2011 at 5:07 PM, Gabriel Dos Reis
g...@integrable-solutions.net wrote:
On Mon, Oct 10, 2011 at 5:25 PM, Joe Buck joe.b...@synopsys.com wrote:
On Fri, Oct 07, 2011 at 07:35:17PM -0700, Gabriel Dos Reis wrote:
C++11 is essentially binary incompatible with C++98.
Only partially.
On Fri, Oct 07, 2011 at 07:35:17PM -0700, Gabriel Dos Reis wrote:
C++11 is essentially binary incompatible with C++98.
Only partially. The layout for user-defined classes is the same, and
code sequences for calls that don't include new features like rvalue
references is the same. Some very
On Mon, Oct 10, 2011 at 5:25 PM, Joe Buck joe.b...@synopsys.com wrote:
On Fri, Oct 07, 2011 at 07:35:17PM -0700, Gabriel Dos Reis wrote:
C++11 is essentially binary incompatible with C++98.
Only partially. The layout for user-defined classes is the same, and
PODness has changed from C++98.
I just noted at http://gcc.gnu.org/bugzilla/show_bug.cgi?id=49561 (due to
std::list), that it's currently impossible to use any C++11-compiled code
in a program which also uses any C++98 code, even if the two pieces of
code never actually touch each other or share objects. After I noted that,
On 7 October 2011 23:24, James Y Knight wrote:
I just noted at http://gcc.gnu.org/bugzilla/show_bug.cgi?id=49561 (due to
std::list), that it's currently impossible to use any C++11-compiled code
in a program which also uses any C++98 code, even if the two pieces of
code never actually touch
P.S. we already document how to link applications using two
incompatible versions of libstdc++:
http://gcc.gnu.org/onlinedocs/libstdc++/manual/abi.html#abi.testing.multi
(whether you can actually make that work in practice is another matter!)
The situation is similar for C++98 and C++11 code, if
On Fri, Oct 7, 2011 at 5:24 PM, James Y Knight f...@fuhm.net wrote:
I guess to start, it would have been nice if there was a big warning on
http://gcc.gnu.org/projects/cxx0x.html telling me not to use c++0x mode
unless there are no objects compiled with c++98 linked into the same
executable.
On Fri, Oct 7, 2011 at 5:24 PM, James Y Knight f...@fuhm.net wrote:
I guess to start, it would have been nice if there was a big warning on
http://gcc.gnu.org/projects/cxx0x.html telling me not to use c++0x mode
unless there are no objects compiled with c++98 linked into the same
On Fri, Oct 7, 2011 at 9:16 PM, Joe Buck joe.b...@synopsys.com wrote:
On Fri, Oct 7, 2011 at 5:24 PM, James Y Knight f...@fuhm.net wrote:
I guess to start, it would have been nice if there was a big warning on
http://gcc.gnu.org/projects/cxx0x.html telling me not to use c++0x mode
unless
FWIW, I seem to have no obvious problems compiling with -std=c++0x,
and then linking with system c++ libraries that were presumably
compiled using default options (e.g., I use the OpenEXR library,
which is C++)
So if there are incompatibilities, they don't seem to be fatal...
-Miles
--
13 matches
Mail list logo