[cxx-abi-dev] C++ ABI version 2

[John McCall]

On Nov 20, 2013, at 9:30 AM, Marc Glisse <marc.glisse at inria.fr> wrote:
> On Tue, 19 Nov 2013, Richard Smith wrote:
> 
>> Would there be support for this idea?
> 
> I thought it was a big NO-NO, so I am happy to hear it isn’t.

Well, to be clear, these would be recommendations for people willing to endure an ABI break.  That would still be a big NO-NO for any established platforms that care about binary compatibility.

And most of these changes are pretty minor improvements; the ABI has really held up very well.

Oh, one thing that Richard forgot:  changing the rules for RTTI uniqueness to reduce the need for coalescing weak RTTI symbols at dynamic load time.  I should probably make that a separate thread, though; Clang and GCC are both doing things in this area, but for slightly different reasons.

>> In off-line discussion with John McCall, we came up with the following list
>> of potential changes that might be made (sorry if I forgot any):
> 
> Maybe revisit some old issues?
> 
> A-9 has the comment: "this won't happen often", but it affects sizeof(tuple<tuple<int>>) in libstdc++. Hmm, no, it doesn't, but it would if they swapped the order of their bases (currently for tuple<int,unsigned> they store the unsigned before the int). Of the 3 permutations tuple<int,E,E>, tuple<E,int,E> and tuple<E,E,int> where E is empty, only 1 has a small size, whereas I believe at most 1 should be large (0 would be great). And that's not the only place I've hit this.
> 
> A-5: gcc and HP seemed to find it hard to implement at the time. Would that still be the case? (it may need to mention move constructors now)
> I seem to be missing the detail that makes it so complicated.

I am not sure how to interpret these comments.  Would you mind translating them into HTML #entity references, or at least section numbers, of the living document at:
  http://mentorembedded.github.io/cxx-abi/abi.html

John.