Albrecht Schlosser wrote: > Michael Sweet wrote: >> Albrecht Schlosser wrote: >>> matthiasm wrote: >>>> >>>> On 19.10.2008, at 13:56, imacarthur wrote: >>>>> I'm always a bit hazy on the whole "what changes affect the ABI" >>>>> thing, but I notice this change has been committed against 1.1.x >>>>> (1.1.10) svn: >>>>> >>>>> - Fl_Group::clip_children() is now public (STR #2017) >>>>> >>>>> Is that a safe thing? Can we do that without breaking the 1.1. ABI? >>>> >>>> >>>> I have done a little research before we decided for the change and >>>> have not found a C++ compiler that encodes "public" attributes in >>>> the decorated method name. This is not to say that there is not some >>>> exotic compiler that does, but at least for the current gcc and >>>> VisualC, these attributes seem to only exist in the header files >>>> (and not changing the ABI). >>>> >>>> I hope... ;-) >>> >>> Meanwhile I found a reference that says that "some compilers mangle >>> the access rights into the function name": >>> >>> <http://tldp.org/HOWTO/Program-Library-HOWTO/shared-libraries.html#AEN135> >>> >>> >>> I don't know how old this may be, or how many compilers might do this. >>> >>> Would this be a reason to revert the change for 1.1? >>> >>> Taken that most FLTK applications will be linked static, maybe not. >> >> Again, the previous clip_children wasn't even available outside the >> library, so ABI concerns are not an issue. > > I'm sorry to insist, but it was protected before (not private, as you > assumed). But it was and is implemented in the header file, so it could > have been inlined by the compiler. Does this change anything for us?
Possibly, however since it was an inline method it shouldn't pose any problems. -- ______________________________________________________________________ Michael Sweet, Easy Software Products mike at easysw dot com _______________________________________________ fltk-dev mailing list [email protected] http://lists.easysw.com/mailman/listinfo/fltk-dev
