This is the mail archive of the libstdc++@gcc.gnu.org mailing list for the libstdc++ project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

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


Hi,
>> so I was finally getting around to adding the new C++1x member functions
> It's still C++0x until we have a final number.
Certainly, I wasn't proposing changing the g++ switch as part of this
email :-)
More seriously, in my informal exchanges I don't use C++0x anymore, it
would be ridiculous, no?
>> to std::time_get (also needed in order to implement the std::get_time
>> free function) when I noticed that we should also add a new *virtual*
>> function, do_get, and that breaks of course the ABI because, eg, on
>> x86_64, the size of the object itself grows from 80 to 88...
>>
>> Off the top of my head, I can't imagine any trick we can play to avoid
>> breaking the ABI when adding an additional virtual, but I admit not
>> being such an expert in this area, and I'm looking for advice...
>
> It already has virtual functions, so it shouldn't affect the size of
> the object.
But it does, even if at the moment I don't know *exactly* why.
>   Adding an additional function to the end of the vtable should be
> backward binary compatible except for derived classes that add virtual
> functions (and therefore append them to the vtable, clashing with do_get).
Declaring it last is enough? I was already doing that anyway, simply
because the new time_get<>::do_get is the last listed virtual in the
actual WD.

In any case abi_check fails because of the size increase :(
> I would bring this up with the library WG, though.
I can do that, but I'm not sure people are really interested, because by
now it's well known that the ABI will be broken, at least in some
implementations, eg, string, list::size...

Paolo.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]