Re: RecentAction doesn't derive from RecentChooser

José Alburquerque wrote:
Jonathon Jongsma wrote:
ABI means Application Binary Interface.  The (huge) benefit of keeping
the ABI stable is that you can switch out the shared gtkmm library to a
newer version and have the apps that link against the library work
exactly as they worked on the old version.  If the ABI of the library
had changed from one version to the next, any applications that used the
library would need to be recompiled, you couldn't just switch to a newer
version of the library. For example, if gtkmm changed its ABI and your linux distribution
updated to that new version of gtkmm, every single application that used
gtkmm would have to be updated as well.
That's the short answer for why maintaining ABI compatibility is a good
I don't know all of the guidelines for maintaining ABI compatibility,
but I know that you have to be very careful with virtual functions,
since they affect the size of an object (by changing the vtable), but
adding regular functions should be ok.
Thanks so much for that, it's already very clear from your explanation! What about constructors? Do they also affect the size of objects?

Searching a bit more, I found the following two links:

I don't see anything in them that would lead me to believe that adding constructors (as in the case of regular functions) would affect ABI compatibility. Thanks.


[Date Prev][Date Next]   [Thread Prev][Thread Next]   [Thread Index] [Date Index] [Author Index]