This is the mail archive of the
libstdc++@gcc.gnu.org
mailing list for the libstdc++ project.
Re: [RFC] C++1x breaking the ABI in one more place :(
I haven't really been that active of a participant on this mailing list in a while but I hope I can contribute some useful thoughts on this discussion.
> I agree with that. But before we do the big break, can we develop a
> scheme which will permit us to avoid big breaks in the future? It's
> been painful to be unable to change class definitions.
Unfortunately, C++ has always been extremely fragile to these kinds of breaks, and the only realistic solution that I can dream up is to have a ++-aware linker / so loader that can construct virtual tables of derived classes and calculate member offsets at link/load time rather than at compile time.
If a derived class in a consumer so were to define its member accesses in a relative form such as MY_BEGIN + MY_MEMBER_X_OFFSET, and MY_BEGIN were a value that could be calculated at link time based on the size (or end offset) of a parent class in another so, then the linker/loader could add the offsets and substitute the appropriate value. That much could probably be implemented over existing linker/loader mechanisms (although I don't know for certain what the so loader does under the hood), and the only really ++-aware requirements would be pasting and overlaying v-table portions together and substituting v-table slot numbers calculated similarly by offsets (or by more sophisticated name/prototype matching).
This wouldn't address compatibility breaks from code or logic changes in inline or templated functions, or changes in default parameter values... but it would remove entire categories of binary compatibility breaks. It's no silver bullet, but I bet it would get rid of plenty of monsters in the realm of binary compatibility issues.
Anybody in favor of raising a feature request to the elf/so team?
- Brian