On 07/03/2012 03:18 PM, Jason Merrill wrote:
2) Object layout changes to std::list and std::basic_string. For these
types, there is no way to both retain backward compatibility with older
C++98 code and conform to the C++11 standard. The best we can hope for
is to allow old code to coexist with
On 07/04/2012 09:41 AM, Richard Guenther wrote:
Btw, why use a bitmask? Isn't it enough to have a single number, viewed
as an ABI suffix?
Well, I think the question is whether we want to create a mechanism
which is only useful for libstdc++ versioning or one which is useful for
ABI changes i
On Wed, 4 Jul 2012, Michael Matz wrote:
> It will by the way not break unnoticed: interfaces using the problematic
> types would be mangled differently, and hence c++98 code would silently
... would _not_ silently ...
> be resolved to a c++11 variant expecting a different layout.
On Wed, Jul 4, 2012 at 3:22 PM, Michael Matz wrote:
> Hi,
>
> On Wed, 4 Jul 2012, Richard Guenther wrote:
>
>> > [... mangling change ...]
>>
>> That would not address the issue of interoperability of a C++03 library
>> with a C++11 program or vice versa if they are using any of the changed
>> int
Hi,
On Wed, 4 Jul 2012, Richard Guenther wrote:
> > [... mangling change ...]
>
> That would not address the issue of interoperability of a C++03 library
> with a C++11 program or vice versa if they are using any of the changed
> interfaces for interoperability. Passing pointers to such objec
On Wed, Jul 4, 2012 at 8:14 AM, Jakub Jelinek wrote:
> On Tue, Jul 03, 2012 at 05:01:29PM -0400, Jason Merrill wrote:
>> On 07/03/2012 03:18 PM, Jason Merrill wrote:
>> >It seems that ELF symbol versioning could be useful for this purpose. If
>> >we were to extend the visibility attribute to also
On Tue, Jul 03, 2012 at 05:01:29PM -0400, Jason Merrill wrote:
> On 07/03/2012 03:18 PM, Jason Merrill wrote:
> >It seems that ELF symbol versioning could be useful for this purpose. If
> >we were to extend the visibility attribute to also handle symbol
> >versions, that could handle a lot of issue
On Tue, Jul 3, 2012 at 1:02 PM, Paolo Carlini wrote:
> Hi,
>
>
> On 07/03/2012 09:18 PM, Jason Merrill wrote:
>>
>> 2) Object layout changes to std::list and std::basic_string. For these
>> types, there is no way to both retain backward compatibility with older
>> C++98 code and conform to the C+
On 07/03/2012 03:18 PM, Jason Merrill wrote:
It seems that ELF symbol versioning could be useful for this purpose. If
we were to extend the visibility attribute to also handle symbol
versions, that could handle a lot of issues. If Wrap uses the GLIBCXX_4
version of string, then Wrap would also be
On 07/03/2012 04:02 PM, Paolo Carlini wrote:
Just wanted to mention / record the case of std::time_get which has an
additional virtual function (do_get) in C++11. I don't think it affects
in important ways the points you are making.
As long as the new virtual function is at the end, it would on
2012/7/3 Paolo Carlini :
> On 07/03/2012 10:10 PM, Daniel Krügler wrote:
>>
>> Isn't there a similar problem with the long long related additions of
>> virtual function to IO/localization as in std::num_get and std::num_put?
>
> Probably not, because, if I understand correctly what you are saying,
On 07/03/2012 10:10 PM, Daniel Krügler wrote:
Isn't there a similar problem with the long long related additions of
virtual function to IO/localization as in std::num_get and std::num_put?
Probably not, because, if I understand correctly what you are saying, we
have long long overloads in C++98
2012/7/3 Paolo Carlini :
> Hi,
>
> On 07/03/2012 09:18 PM, Jason Merrill wrote:
>>
>> 2) Object layout changes to std::list and std::basic_string. For these
>> types, there is no way to both retain backward compatibility with older
>> C++98 code and conform to the C++11 standard. The best we can
Hi,
On 07/03/2012 09:18 PM, Jason Merrill wrote:
2) Object layout changes to std::list and std::basic_string. For
these types, there is no way to both retain backward compatibility
with older C++98 code and conform to the C++11 standard. The best we
can hope for is to allow old code to coexi
14 matches
Mail list logo
