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.
Ja
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, bu
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 Mon, Oct 10, 2011 at 5:07 PM, Gabriel Dos Reis
wrote:
> On Mon, Oct 10, 2011 at 5:25 PM, Joe Buck 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 t
On Mon, Oct 10, 2011 at 5:25 PM, Joe Buck 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.
> code sequences
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 imp
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
--
Hers
On Fri, Oct 7, 2011 at 9:16 PM, Joe Buck wrote:
> On Fri, Oct 7, 2011 at 5:24 PM, James Y Knight 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 w
On Fri, Oct 7, 2011 at 5:24 PM, James Y Knight 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.
Gabriel
On Fri, Oct 7, 2011 at 5:24 PM, James Y Knight 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.
I was und
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 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
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,
paolo
13 matches
Mail list logo
