binary compatibility and qwidget::event
Hey our binary compatibility page [1] states that one should "reimplement event in QObject-derived classes, even if the body for the function is just calling the base class' implementation." Does anyone know the reason this helps maintain BC? [1] https://community.kde.org/Policies/Binary_Compatibility_Issues_With_C%2B%2B HS
Re: binary compatibility and qwidget::event
To avoid situations like [1] and [2] [1] https://cgit.kde.org/kiconthemes.git/commit/?id=1e9af6c54470e890597739f8f2189b0743a00b6f [2] https://cgit.kde.org/kiconthemes.git/commit/?id=083bb8a80fd5941e6fcbaf1ec12a08d8f8c881a5 Am 12.07.19 um 11:14 schrieb Harald Sitter: Hey our binary compatibility page [1] states that one should "reimplement event in QObject-derived classes, even if the body for the function is just calling the base class' implementation." Does anyone know the reason this helps maintain BC? [1] https://community.kde.org/Policies/Binary_Compatibility_Issues_With_C%2B%2B HS
Re: binary compatibility and qwidget::event
But why was that BIC to begin with? Which of the "don'ts" did it violate? On Fri, Jul 12, 2019 at 11:18 AM Kai Uwe Broulik wrote: > > To avoid situations like [1] and [2] > > [1] > https://cgit.kde.org/kiconthemes.git/commit/?id=1e9af6c54470e890597739f8f2189b0743a00b6f > [2] > https://cgit.kde.org/kiconthemes.git/commit/?id=083bb8a80fd5941e6fcbaf1ec12a08d8f8c881a5 > > Am 12.07.19 um 11:14 schrieb Harald Sitter: > > Hey > > > > our binary compatibility page [1] states that one should > > > > "reimplement event in QObject-derived classes, even if the body for > > the function is just calling the base class' implementation." > > > > Does anyone know the reason this helps maintain BC? > > > > [1] > > https://community.kde.org/Policies/Binary_Compatibility_Issues_With_C%2B%2B > > > > HS > > > > >
Re: binary compatibility and qwidget::event
On Friday, 12 July 2019 11:24:35 CEST Harald Sitter wrote: > But why was that BIC to begin with? Which of the "don'ts" did it violate? IIUC re-implementing a virtual method from a base class (in absence of complications like multi-inheritance or co-variant return types) does not change the ABI (it changes vtable content, but not vtable layout). It does however create cases where old binaries still call the old methods (see https://community.kde.org/Policies/ Binary_Compatibility_Issues_With_C%2B%2B#Adding_a_reimplemented_virtual_function). That might not always be a relevant problem though. In my understanding this is the same for the final -> !final case discussed in #plasma in this context. It does not impact the ABI at all (it does not even change vtable content), but some optimizations in old binaries might no longer reflect the new behavior. Regards, Volker > On Fri, Jul 12, 2019 at 11:18 AM Kai Uwe Broulik wrote: > > To avoid situations like [1] and [2] > > > > [1] > > https://cgit.kde.org/kiconthemes.git/commit/?id=1e9af6c54470e890597739f8f2 > > 189b0743a00b6f [2] > > https://cgit.kde.org/kiconthemes.git/commit/?id=083bb8a80fd5941e6fcbaf1ec1 > > 2a08d8f8c881a5> > > Am 12.07.19 um 11:14 schrieb Harald Sitter: > > > Hey > > > > > > our binary compatibility page [1] states that one should > > > > > > "reimplement event in QObject-derived classes, even if the body for > > > the function is just calling the base class' implementation." > > > > > > Does anyone know the reason this helps maintain BC? > > > > > > [1] > > > https://community.kde.org/Policies/Binary_Compatibility_Issues_With_C%2 > > > B%2B > > > > > > HS signature.asc Description: This is a digitally signed message part.
