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? If you asked me, I would say: the possibility of name mangling could be a problem, but since it was and is in the header file, we shouldn't get problems, but ... I don't know. Albrecht _______________________________________________ fltk-dev mailing list fltk-dev@easysw.com http://lists.easysw.com/mailman/listinfo/fltk-dev
