24.05.2019, 13:32, "Konstantin Tokarev" <annu...@yandex.ru>: > 24.05.2019, 13:06, "NIkolai Marchenko" <enmarantis...@gmail.com>: >> All of the back and forth on this issue recently and over the years really >> make want to ask this question: >> >> Is the promise of SC worth all the potenital pitfalls? There seems to be no >> end to the discussion with every solution requiriring hair rising >> compromises. >> Is it _really_ that impossible to just remove QLIst entirely and force user >> to choose form a range of classes each tailored for the specific scenario >> that QList tried to cover? >> >> As it is, it seems like we're rapidly heading to a nightmarish scenario >> worse than any SC breakage, where users will have to looks for problems in a >> perfectly compiling code. >> >> Is the gordian knot of full SC really possible to unravel or is it time to >> axe it? > > If we remove QList, users with thousands of occurrences of QList in code base > will likely do > mechanical replacement s/QList/QVector/g, or use the same template alias as > it was proposed > earlier in this thread. > > To axe this problem, automatic clang-based porting tool is needed. Such tool > would analyze > context and do a replacement of QList to QVector in places where it's least > likely to introduce > issues, e.g. where QList is used with movable types which are not larger than > void*, or where > QList is used as a local variable and it's possible to prove that references > or iterators pointing > to this local QList members are never used after QList modification. > > If users end up with little manual work, it's more likely that they will > carefully analyze all remaining > cases.
Actually, clazy provides related checks "inefficient-qlist". I think following plan can work: 1. Implement opposite "replace-efficient-qlist-to-qvector" check in clazy which finds QList<T> where sizeof(T) <= sizeof(void*) and T is movable, and allows automatic replacement with QVector 2. Apply this transformation to all public and private Qt APIs, and refrain from QList replacements in places which are not sanctioned by tool. 3. Implement clazy check "inefficient-qvector-insert" which warns when prepend/push_front and insert into middle are used with QVector. Algorithm of porting to Qt 6 could be: 1. Run inefficient-qvector-insert over code base and store results 2. Apply replace-efficient-qlist-to-qvector to whole code base 3. Run inefficient-qvector-insert again and make a diff with step 1, and suggest user to check these cases carefully for possible reference issues and performance regressions Results: 1. Do a big chunk of worldwide QList elemination without compatibility hacks and with relatively low risk 2. Users should finally get the message that QList is not the go-to container preferred in most cases. Porting other part of QList usages can be delayed to Qt7. -- Regards, Konstantin _______________________________________________ Development mailing list Development@qt-project.org https://lists.qt-project.org/listinfo/development
