[Development] Question about QCoreApplicationData::*_libpaths

[Marc Mutz]

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.mutz at kdab.com> | Senior Software Engineer
KDAB (Deutschland) GmbH & Co.KG, a KDAB Group Company
Tel: +49-30-521325470
KDAB - The Qt Experts