On 21.05.2012 20:14, Greg Ercolano wrote: > I was thinking about that as I was developing, but noticed > Fl_Tooltip was one of those classes that's referenced by > 'lower level' classes (Fl, Fl_mac, Fl_win32, Fl_Widget, etc.) > so I wasn't sure if there might be some code elsewhere in FLTK > that might somehow cause trouble.
I wouldn't think that this can really cause troubles, if the code in Fl_Tooltip is designed and coded properly. > The thing that scares me the most is code changes made to > both .H and .cxx files that depend on each other to work > properly. This can cause trouble in DLL scenarios where > the app compiled against an old .H file that contains logic > incompatible with the new logic implemented in the newer .H/.cxx > files of the lib, causing a negative reaction at runtime (**). Well, that's really another kind of problem, and it is also stated in the referenced document, but this is *re-implementing* a method, not adding another one. > This kind of thing doesn't seem to break any rules of the ABI, > but actually does end up breaking the app. Indeed, it can... > ** Not sure if this is a good example, but here's what I mean, > as it was a situation like this that leveraged me into coming up > with ABI feature macro as a workaround. > > In the following, the changes would /appear/ not to break ABI rules, > but still kinda does. Your example shows that re-implementing a method with inline code is bad and should only be done if it doesn't break anything else. Citation from the document mentioned above: "You can ... change an inline function or make an inline function non-inline if it is safe that programs linked with the prior version of the library call the old implementation. This is tricky and might be dangerous. Think twice before doing it." See the last two sentences. > Perhaps the definition of this isn't 'breaking ABI' so much > as 'writing bad code', but if this were buried in more complex > changes, it'd be easy to miss. > > If the constructor had been declared in the .cxx file > instead of as an inline, there'd be no trouble. > > So it's not so much the code is 'bad', just that because > the logic crosses .H and .cxx, it can cause trouble for DLL's. There's always a problem with code implemented in header files, since it is always compiled into the application and can't be exchanged with another dll/so version. But I think all your code added were *new* versions of static methods, so there shouldn't be any problems, AFAICT. Albrecht _______________________________________________ fltk-dev mailing list fltk-dev@easysw.com http://lists.easysw.com/mailman/listinfo/fltk-dev
