Re: [RFC] C++1x breaking the ABI in one more place :(

[Gabriel Dos Reis <gdr at integrable-solutions dot net>]

On Thu, May 20, 2010 at 6:17 PM, Mark Mitchell <mark@codesourcery.com> wrote:
> Gabriel Dos Reis wrote:
>
>>> I do think the earlier suggestion of "add a few spare vtable slots" is a
>>> good bit of future-proofing, in that it improves the odds that any given
>>> change will be ABI-compatible.
>>
>> How many "spare vtable slots" is future-proof? 12? 24? 1024? 1G?
>
> Obviously, no number is sufficient in theory. ?But, even two or three
> would probably be sufficient in practice, and cost just a few bytes. ?It
> seems like a good call.
>
>> Personally, I believe that the risk posed by the original patch is being
>> inflated beyond the reasonable.
>
> My view of this is that either you maintain ABI compatibility or you
> don't. ?Once you start guessing about what you can get away with, I
> think you've already lost.
>
> One of the reasons I feel that way is that to convince users you're
> serious you have to an unambiguous answer. ?Once you start saying "We
> maintain compatibility, except ..." you lose credibility with your
> audience, who often doesn't know whether it's codebase might or might
> not be affected. ?I think G++ has gotten a bad reputation around this
> point, and that we can restore that reputation by being unambiguous:
> unless we change the .so version, it's compatible. ?Period.

The bad reputation G++ has cultivated does not come from situation
remotely close to what the original patch was about.  G++ bad reputation
comes extensions that were introduced without much thought about
interactions, and that were removed later, etc.  The concrete
situation at hand comes from a change in the C++ standard itself.
We should not be conflating the two.  Otherwise, we lose credibility.