[Development] Qt 5 types under consideration for deprecation / removal in Qt 6
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
> 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
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