On 2019-06-03 14:27, Bernhard Lindner wrote:
> > > So, yes, this is borne out of frustration with the lack of maintenance
> > > of QtCore plumbing. I don't see that changing and I acknowledge and
> > > understand that the focus of development has shifted towards QML.
> > Suppose you implement all planned actions for Qt6 (see your original
e-mail). Are
> > the
> > remaining components (those that are neither deprecated nor removed) of Qt6
well
> > maintained and are there enough staff available not only to maintain them
> > indefinitely
> > but to actively develop them further?
>
> No answer to my question above?
Who do you expect an answer to this question from?
The Qt Company? The Qt community? Marc? Thiago?
Whoever believes being able to make a realistic assessment.
If there is no such person/group in this list, which can do an
estimate how much of Qt is
affordable, an important aspect of the Qt 6 discussion can not
actually be discussed. How
can Marc think about removing (or significantly changing) Qt due to
ressource limits or
new strategic goals if the limits or goals are unknown?
Actions out of frustration are never a good idea. And pushing into a
(technical) direction
that does not solve the underlying (strategical) problem is futile.
I think it's pretty clear that some parts of Qt thrive (e.g. QString)
and others, incl. the other containers, lag behind. I can't speak for
TQC, but I do wonder where all the manpower that is now proposed to make
Qt containers wrappers around std ones, etc, suddenly should come from
when it was lacking for the last decade.
An example: The Qt docs made fun of how hard it is to iterate backwards
using STL containers, as opposed to Java-Style ones
(https://doc.qt.io/archives/qt-4.8/containers.html#java-style-iterators),
yet, in roughly the same time it took to write that nonsense, a
developer could have implemented rbegin()/rend() on Qt containers.
Likewise, since I added rvalue-push_back to QVector a few years ago,
no-one stepped up to implement this for everyone's favourite container,
QList. Nor any other Qt container. Not _one_. This, and many other such
instances, show me that the Qt containers are considered good enough,
and there's absolutely no interest in bringing them forward into the
21st century. If you believe otherwise, prove it.
But containers are one of the cornerstones of programming, and there's a
reason that we now have emplacement, node_handle, move-only payload type
support, splicing, etc. etc. Where are those functions on Qt containers?
For that matter, why is there no Qt version of std::set? I removed at
lest three implementation of an OrderedSet that used a QMap<V,bool> to
imitate a std::set from QtCore alone. Where is that container, please?
Where is QDeque? Where is QForwardList? Where is the 25-year-old
optimisation that implements Container<T*> in terms of Container<void*>.
IIRC, even the original STL had that. Where is the const_iterator
overload of QVector::erase()? In particular with CoW, only detaching if
you actually found the object should be something that everyone yearns
for. People complain that std::mutex is slower than QMutex, but they
don't complain that erase(const_iterator) is missing.
You don't need a crystal ball to see that there's not even enough
manpower to bring in the "recent" (well, C++98 is 20 years ago) changes
from the STL, let alone innovate.
If users use a QMap<T,bool> because they have an aversion against
std::set, for one reason or another, where _is_ the Qt answer? Since
4.0, the answer has been "you're on your own". So, the honest answer
would be that Qt doesn't care about it's container classes any more, and
recommends every user to move over to the STL versions where-ever they
can.
But some people still live in a bubble universe where, contrary to
historic proof, the Qt containers will be made great again, any-time
soon now. Just wait for it...
Thanks,
Marc
_______________________________________________
Development mailing list
Development@qt-project.org
https://lists.qt-project.org/listinfo/development
