Re: RecentAction doesn't derive from RecentChooser

[José Alburquerque <jaalburquerque cox net>]

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
> > thing.
> > 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:

http://scm.opendap.org:8090/trac/wiki/libdapABIStability
http://www.cprogramming.com/tutorial/size_of_class_object.html

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.

-Jose