> On 25 Aug 2023, at 14:20, Ahmad Samir <a.samir...@gmail.com> wrote: > > On 25/8/23 14:11, Cristian Adam via Development wrote: >> The other way of fixing this is by using ... macros. The article at c++ - >> Importing inline functions in MinGW - Stack >> Overflow<https://stackoverflow.com/questions/11546403/importing-inline-functions-in-mingw> >> mentions using inline in the class declaration. >> Their example works fine with both GCC MinGW and Clang MinGW. Visual C++ is >> also fine: >> #ifdef _WIN32 >> #define Q_EXPORT_INLINE inline >> #else >> #define Q_EXPORT_INLINE >> #endif >> class __declspec(dllimport) MyClass { >> public: >> Q_EXPORT_INLINE int myFunc2(); >> Q_EXPORT_INLINE int myFunc1(); >> }; >> inline int MyClass::myFunc2(void) { >> return myFunc1(); >> } >> inline int MyClass::myFunc1(void) { >> return 0; >> } > > [...] > > The main deterrent to not fix it like the qstring.h patch[1] is the churn > caused by changing many lines, in many files, right? > > But if affected code is going to be changed anyway to fix it with macros, it > makes more sense to fix it like [1]; if you're changing those lines, may as > well adhere to more standard guidelines: inline keyword is only used on > function declaration and _not_ the definition. > > > My 2p's. > > [1] https://codereview.qt-project.org/c/qt/qtbase/+/498739
Yes, if we have to change the code to fix the warnings, then the way Marc proposes, and how it has now been done for qstring.h, seems to be the way to go. But yes, my concern is the work (I expect this can be easily automated with clazy, but still need to be reviewed), and the code churn that goes with it (the impact on `git blame`, and the inevitable conflicts when cherry-picking). It seems to be a rare issue, triggered by specific circumstances. With the knowledge that we have now, we can fix issues when they arise, and don’t have to change all the problematic use right now. That’s my understanding at least; I might be wrong, but we have been building Qt for a few decades on MinGW without this constantly blocking us. Volker -- Development mailing list Development@qt-project.org https://lists.qt-project.org/listinfo/development
