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

Matthew Woehlke mwoehlke.floss at gmail.com
Tue Jun 11 21:21:20 CEST 2019

On 04/06/2019 16.41, Mutz, Marc via Development wrote:
> On 2019-06-03 11:26, Lars Knoll wrote:
>>> == QSharedDataPointer / QExplicitlySharedDataPointer ==
>> I see no reason at all for removing those, quite to the contrary. They
>> are very helpful for building refcounted classes (explicitly or
>> implicitly shared).
> I'd still like to deprecate them. QSDP is issuing atomic operations on
> each mutable access hurting code-gen, and produces surprises such as
> https://codereview.qt-project.org/gitweb?p=qt%2Fqtbase.git;a=commit;h=96dc9a19ae11ca140d681f0e2605b5f4b953e581
> or
> https://codereview.qt-project.org/gitweb?p=qt%2Fqtbase.git;a=commit;h=a2cdfd23d61c8dd3a346982caaf1e846e30513b0
> or
> https://codereview.qt-project.org/gitweb?p=qt%2Fqtbase.git;a=commit;h=188eea0eb47c499f70a60f573948d529089d93b1.
> 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.

As one of the users that would be affected by such a change... I want to
go on record that I would be fine with *replacing* these... just as long
as there *is a replacement*, and that replacement isn't "for Qt-internal
use only".

I don't mind porting my code, especially if there are notable
improvements in doing so. I *do* mind suddenly having to reimplement
something that Qt used to provide that doesn't have an STL replacement.

(p.s. It would also be nice if Q_D and friends would also stop being

BTW, in qtExtensions, I have explicit QTE_D_SHARED / QTE_D_MUTABLE to
differentiate getting a mutable d-pointer (which might detach) and an
immutable one (which won't).

m> 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)?



The converse (always having to write `.second`, not to mention the
*name* "second") has its own annoyances.

In an ideal world, we could do something like:

  for (auto k : map | keys)

...and have optimal codegen.


More information about the Development mailing list