On Tuesday 19 January 2016 18:34:48 Thiago Macieira wrote: > On Tuesday 19 January 2016 19:16:25 Marc Mutz wrote: > > That may be so. But most of what is _missing_ is implementable in Qt 5: > > > > - equal_range on hashed containers > > No idea what that is.
http://en.cppreference.com/w/cpp/container/unordered_map/equal_range It's the correct way to find all values matching a given key (as opposed to QHash::values(const Key &), which forces a QList down your throat). > > - range inserts, ctors, assignments > > Already done for QVector for Qt6. However, since I wrote this on top of > QGenericArray, I can't push it to Qt 5. I don't understand this. It can clearly be implemented in Qt 5, so what you're saying is that you implemented it in a Qt 5-incompatible fashion and _won't_ (as opposed to "can't") backport? > > - exception safety guarantees > > Done since Qt 5.0 by João, but missed the release deadline. It's > QGenericArray using QArrayDataPointer and QArrayDataOps. > > Also, we changed our policy towards exception-safety since 5.0 and this > work is no longer needed. Sending your user's needs to /dev/null is a very easy way to fix it, yes. This is what I meant and what Lars called me polemic for. *Qt* doesn't need this → we don't care. But please, everyone, use our super-cool containers and not the shitty STL ones, because we use camelCase and they use underhanded_names. Argh... BTW: here and in the following, I'm not saying *you* should implement all this. I'm just picking on you because a) I know you can take it and b) it exemplifies very well what started this thread (back when this was still about std::optional and why QOptional would be a bad idea). > > - move semantics on realloc / insertions > > This is easy to implement in QArrayDataOps. However, due to CoW, we'd have > to duplicate the code paths depending on whether the refcount was 1 or > not. That's a runtime decision, so I don't think this is worth it. Oh, CoW again... Howard Hinnant has reported a 10x (or was it 100x?) slowdown on std::vector<std::string> reallocation, depending on whether the std::string move ctor was marked as noexcept (std::vector refuses to move during reallocations when the type isn't nothrow_move_constructible). So, very much worth it, I think. > > - emplace (with Q_COMPILER_UNIFORM_INIT ifdef) > > Done in QGenericArray, but not really relevant since we don't support move- > only types. emplace is not about move-only types. move-only types can be appended with push_back(T&&). emplace is about constructing into the final place. Without any move or copy ctor called. As Alexandrescu put it: no work is less work than some work. > > - not requiring op= / default ctor in QVector > > Not interesting to me. That wouldn't be a problem if it would be interesting to *anyone*. Again, development stopped half-way. And this is a very annoying one. When porting from QList (which doesn't require default ctors), you end up adding an artificial default ctor to the payload type, which, surprisingly often, doesn't have one. Well, or you skip QVector and go directly to std::vector and save that nonsense. > > - move-only payload types (hard with CoW) > > Ditto. Which means QVector will not be able to hold unique_ptrs or std::threads. Well done. > > - splicing in node-based containers (hard with CoW) > > Ditto and no one has asked this in 10 years that QLinkedList has existed. Because no-one uses that container. In 100% of cases _I_ used std::list, it was because it had splice(): nothrow move from one std::list to the next in C++98: https://code.woboq.org/kde/kdepim/kleopatra/smartcard/readerstatus.cpp.html#509 peeling off one object from a std::list without so much as resetting four pointers: https://code.woboq.org/kde/kdepim/kleopatra/smartcard/readerstatus.cpp.html#554 I later learned that Herb Sutter calls this idiom an "acceptable poor man's concurrent queue". And again: *Qt* doesn't need this → we don't care. > > - atomic operations on QSharedPointer > > Explain more, please. You can CAS on a shared_ptr instance, as if it was a normal pointer: http://en.cppreference.com/w/cpp/memory/shared_ptr/atomic > > - alias ctors for QSharedPointer > > Ditto. http://en.cppreference.com/w/cpp/memory/shared_ptr/shared_ptr ctor #8 > > - changing iterator → const_iterator in insert / erase argumentsis > > > > (hampered by QT_STRICT_ITERATORS preventing iterator → const_iterator > > implicit conversions, otherwise one could write erase loops over > > > > node-based containers that only detach when actually removing an element) > > Sounds like a Qt 6 change. Adding overloads is possible. Thanks, Marc -- Marc Mutz <marc.m...@kdab.com> | Senior Software Engineer KDAB (Deutschland) GmbH & Co.KG, a KDAB Group Company Tel: +49-30-521325470 KDAB - The Qt Experts _______________________________________________ Development mailing list Development@qt-project.org http://lists.qt-project.org/mailman/listinfo/development
