> On 5 Jun 2019, at 00:39, Kevin Kofler <kevin.kof...@chello.at> wrote: > > Mutz, Marc via Development wrote: >> I'd still like to deprecate them. QSDP is issuing atomic operations on >> each mutable access hurting code-gen, > > Well yes, you have to use constData() or cast to const where needed. That > does not reduce QSharedDataPointer's usefulness. It is an implementation > tool for people who know what they are doing. > >> and produces surprises such as >> https://codereview.qt-project.org/gitweb?p=qt%2Fqtbase.git;a=commit;h=96dc9a19ae11ca140d681f0e2605b5f4b953e581 > > My existing QSharedDataPointer code always checks truth with > if (d.constData()) and never if (d). > >> or >> https://codereview.qt-project.org/gitweb?p=qt%2Fqtbase.git;a=commit;h=a2cdfd23d61c8dd3a346982caaf1e846e30513b0 > > I haven't had a need for this idiom in my code yet, but instead of using > QExplicitlySharedDataPointer, I would have fixed it by adding some casts to > const for the read-only checks (probably with something like: > #define CD ((const QSharedDataPointer<Foo> &)(d)) > to cut down on copy&paste). > >> or >> https://codereview.qt-project.org/gitweb?p=qt%2Fqtbase.git;a=commit;h=188eea0eb47c499f70a60f573948d529089d93b1. > > I'm not sure I understand the issue there. Thanks to the atomic reference > counts, implicitly-shared classes are as thread-safe as plain classes > without the CoW magic. But writing to the same object from 2 threads without > some form of mutex will work in neither case. Just don't do that. > >> QESDP has the bug that it doesn't propagate const. We could fix that, >> but it would be SiC, too. So, my idea was to keep them both, deprecate >> them, and use something much more cumbersome to use outside of Qt for >> Qt's own classes. I'd also be ok with keeping a fixed QESDP, but QSDP >> should go sooner rather than later. > > No, QSharedDataPointer must not go away, not now… > >> That said, I'm ok with keeping them until Qt 7, but deprecated. > > … and not in Qt 7 either! > >>>> == Java-style iteration >>>> (https://codereview.qt-project.org/c/qt/qtbase/+/262344) == >> [...] >>> I’m a bit torn here. On code review I gave a +1 on deprecating them, >>> but I see that this could lead to a lot of porting effort on user code >>> that makes extensive use of them. And the problem is that the porting >>> can be non-trivial in cases where the list gets modified while >>> iterating. So I think we should most likely keep them for Qt 6. >> >> As I wrote in the other thread, I'm ok with keeping them. I'd like to >> deprecate them, though. > > Deprecating them means you don't want to keep them permanently though, and I > don't see why. They not only help developers coming from a Java background, > but are also more intuitive for new developers. > > Yes, the STL-style iterators are more powerful in some ways, and yes, they > are needed to use STL algorithms on the Qt containers. But nobody is taking > them away from you anyway. It just does not preclude also offering a more > developer-friendly API. > >>>> == QLinkedList -> std::list >>>> (https://codereview.qt-project.org/c/qt/qtbase/+/261421) == >> [...] >>> It’s not used a whole lot, and I’m not against deprecating it. But do >>> we need to remove it for 6.0? Or maybe go the route we thought about >>> for other containers as well and have it wrap a std::list. ie. remove >>> our implementation, keep our API. >> >> I'd just let it sit in it's place, deprecated, untouched. It's not used >> in any Qt API, and the uses which I found in Qt are questionable to >> begin with. > > There too, "just let it sit in it's place, deprecated, untouched" is a > contradiction: if you deprecate it, it is not going to "sit in its place" > forever. But a data structure as common as a linked list should not go away. > (Especially not if the datastructure with the next-fastest random-access > inserts and removals, the array of pointers, is also going away.) > >> I'm concerned about their use in APIs. I don't know any other library >> that is passing hash tables around through the API for small things like >> mapping role indexes to role names. That's an array of struct job. > > Passing around a map is exactly what a hash table like QHash or a tree map > like QMap are for. I have seen lots of APIs in various programming languages > using them for the purpose they were designed for, and even written some of > them myself (both in C++ with Qt and in other programming languages). > >> How do you intend to address the problem that QHash/QMap are all but >> unusable in C++11 ranged for loops, because of decltype(*it)? > > Can't we just add a keySet() method (named after the Java one that does > something similar) that returns a wrapper object that just forwards begin() > to the map's keyBegin() etc.? Then you could just write something like: > for (auto key : map.keySet()) > and it should do conceptually the same as: > for (auto key : map.keys()) > but without ever having to build the list of keys as a list. > > Or, probably even more efficiently, add cursorBegin() etc. iterator methods > that return iterators returning key-value pairs as QPair, and a cursorSet() > that returns a wrapper object for them like keySet() above. Then: > for (auto cursor : map.cursorSet()) > would get you key-value pairs, wouldn't it?
Since Qt 5.10, QHash and QMap have something for that: https://doc.qt.io/qt-5/qhash.html#keyValueBegin https://doc.qt.io/qt-5/qhash.html#keyValueEnd And their corresponding const versions. Note that the iterator returns a std::pair. Best regards Samuel -- Samuel Gaist Research And Development Engineer Idiap Research Institute, Centre du Parc, CP 592, CH-1920 Martigny http://www.idiap.ch/ _______________________________________________ Development mailing list Development@qt-project.org https://lists.qt-project.org/listinfo/development
