[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.)

-- 
Matthew



More information about the Development mailing list