#YACREADER UBUNTU FULL#
This would make C++17 a good milestone for YACReader 9.9, at which point we also could re-asses the Ubuntu situation regarding full C++17 support. Porting or testing to Qt6 will make little sense before Qt 6.2 is released since Qt6 does not provide all modules we require yet, so it is unlikely we will do that for YACReader 9.8. Qmake 5.9 does not support CONFIG+=c++17, so we will have to add it to the compile flags manually. There is also the question of build chain support. I'm not thinking about big rewrites here but more along the lines of elimination of deprecated code, tool assisted refactoring for stuff like old style SIGNAL SLOT connects and the like. Personally I would prefer to get our code into a better shape first, so we've got our backs covered before marching forward. IMHO moving to c++17 is the obvious next step, but we should consider when to do it. I have copied these here so the discussion has a proper place. in ConcurrentQueue::cancellPending() modifies _queue while the wrong mutex is locked #201.
in Feature: make comic vine dialog more keyboard friendly #228Ībout c++17, since Qt6 adopts c++17 and we want to move in that direction I think it is reasonable to start using it too.The newer standard makes development more fun and motivating. If we don't have to support old Clang and MSVC versions, C++17 should be almost completely supported on Mac and Windows too. Could we perhaps increase the C++ standard version to C++17 too? Ubuntu 18.04's GCC 7.4 supports almost all C++17 features: and. Ubuntu 16.04 is supported only until April 30th, 2021. I'm all for increasing minimum supported Qt version in order to be able to use things like qOverload and other features introduced between versions 5.6 and 5.9.
0 kommentar(er)
