On Fri, Apr 24, 2020 at 09:33:49AM +0200, Christian Ehrlicher wrote: > Am 24.04.2020 um 09:22 schrieb Lars Knoll: > > > e "vector is a silly name from a mathematical standpoint" argument is > > > valid, > > > but vector is an established term in C++ world. Sorry, that ship has > > > sailed. > > > I am also in favor of proposal 2 or 3. I think deprecating either QList or > > > QVector without any big advantage for the user will just make porting form > > > Qt5 to Qt6 needlessly harder. > > > > > > Even inside Qt we are struggling to keep up with deprecation warnings > > > (Thanks to Friedemann for fixing these). I am pretty sure Creator does > > > have > > > the same "problem". Extrapolating that from "just us" to the broader > > > audience we are hopefully targetting, it looks like lots of > > > users/applications will be hit by these warnings and it will mean (lots > > > of?) > > > work for them. > > I do agree that we shouldn’t deprecate neither name, as that would just make > > moving from 5 to 6 harder. The unification of the classes should help > > simplify > > things. > > > > But we need to have a consistent message around which name is the preferred > > one and used in Qt’s own API and documentation. Having a QList in one method > > and a QVector in the next one would only be confusing to our users. So IMO > > this thread should mainly be about deciding what the default name for this > > container is in our documentation and API in Qt 6. > > Since you tell everyone since ages that QList should not be used (it's in the > documentation since 5.6: > https://doc-snapshots.qt.io/qt5-5.9/qlist.html#details
Sorry. There was never an *agreement* on the issue. QList(<=5) was designed and implemented to be a convenient, easy-to-use one-size-fits-all container for use cases in user facing application that was hard to completely get wrong even for C++ newbies, including "unreasonable" use cases like being able to access by index *and* to insert big objects in the middle without completely killing performance. It was never meant to be the best performing nor the smallest container for a given fixed use case *by design*. Consequently, it was very easy to find setups were there where better alternatives. In fact, in almost all setups there was *some* other container that was smaller or faster, it was "just" not always the same container. From that some people draw the conclusion that QList was a bad thing and started lobbying for its demise in blog posts, conference talks and here on the mailing list. Over time this was successful, at some time in the documentation the comment on the default choice was flipped and for Qt 6 the implementation was shared with QVector. For this discussion here now the interesting consequence is that by the new sharing of the implementation with QVector all the implementation related arguments against QList that have been made in the past are void, all those arguments do *not* apply to QList(>=6), at least not unless you extend them to QVector, see below. When you now look at the 2010 blog post you'll notice that *none* of the performance and size claims in there apply to QList(>=6). So what is left is the question about what is in the name. That question was interestingly enough not present at the begin of the crusade, it only came up after it turned out that blind replacement of QList by QVector wasn't *that* trivial and actually caused performance regressions in real world applications, i.e. the performance argument made against QList wasn't quite as uniformly applicable as initially presented. Today the main line of reasoning given is that QVector is something like std::vector and people knowing C++ would feel comfortable using it the same way. And that would be a false friend. QVector is refcounted, so it *also* trades cycles (e.g. for write access) for convenience (return by value without further decoration? No problem!) This is still exactly the same quality of compromise QList was accused of for a decade now, all the arguments made against compromises in principle could be made against QVector as well. Replacing *now* all QList uses by QVector would be a lose-lose situation. People aiming at the ability to use a std:: container of their choice will not be content, as it's still not a std:: container, both in name and behaviour. Everyone else will have to adapt their code or live with the uncomfortable feeling about not using the most recent name. It's still possible, and easy, to limit the damage to one of the factions, and that's what I understand is what the proposals here were aiming at. Andre' _______________________________________________ Development mailing list Development@qt-project.org https://lists.qt-project.org/listinfo/development
