[Development] Qt 5 types under consideration for deprecation / removal in Qt 6

Matthew Woehlke mwoehlke.floss at gmail.com
Tue Jun 11 18:59:51 CEST 2019

On 05/06/2019 10.23, Elvis Stansvik wrote:
> Den ons 5 juni 2019 kl 12:59 skrev Mutz, Marc via Development:
>> [...] This, and many other such instances, show me that the Qt 
>> containers are considered good enough [...]
> I guess that is the case. At least I haven't craved for any of the
> features you list in the 15 or so year's I've developed with Qt. The
> plumbing has been good enough both for my personal and professional
> projects, and I guess that may be the case for many others as well.

Okay... I'm going to jump in here.

On the one hand, I agree with Kevin; Qt's API is *monumentally* better
than STL. I really wish that could be done over. (And I really, *really*
hate that STL doesn't have the equivalent of Q{Hash,Map}::value()...)

On the other hand, Marc is right that Qt's containers are missing modern
features. I recently used a QMap<T, nullptr_t> in new API¹. I've also
had numerous occasions where I've had to use STL containers because I
needed to use move-only types. Or, even, because my value type is a
shared pointer and I didn't want to pay the cost of an extra pair of
reference counting operations on insert.

Because of the API and CoW, I still prefer to use Qt containers where
possible, but unfortunately there are quite a few instances when I can't.

(¹ In particular, I needed to extract the keys of a QMap as a QMap. A
"proper" implementation of this can probably be done fairly efficiently,
but there is no such API in Qt, currently. Then again, STL has no such
method, either.)


More information about the Development mailing list