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. If we are not ready to provide such tool before 6.0 release, IMO it would be better to avoid touching QList at all, and instead concentrate on removing QList from public APIs. In this case users can start porting their code from places where conversions between QList and QVector introduce visible impact on performance, and start writing new code with QVector. -- Regards, Konstantin _______________________________________________ Development mailing list Development@qt-project.org https://lists.qt-project.org/listinfo/development
