[Development] RFC: Proposal for a semi-radical change in Qt APIs taking strings
Marc Mutz
marc.mutz at kdab.com
Sun Oct 18 09:24:52 CEST 2015
On Saturday 17 October 2015 22:42:35 Konstantin Ritt wrote:
> > The whole problem of QString::fromRawData is that the method you called
> > may store the QString and thus keep referencing the string you had, even
> > past the
> > point where your string changed.
> >
> > In fact, that happens with QStringLiteral too. If you use QStringLiteral
> > in a
> > plugin and the plugin gets unloaded, the application may crash.
>
> Indeed, it is the same issue. QStringView doesn't solve it either.
> So the best thing we can do, IMO, is to give the user a tool and describe
> how to use it properly to get some extra performance, on his own risk.
Since QStringView doesn't (ever) own, it does solve the problem. If a plugin
returns a static-storage duration string through QStringView istead of
QString, a user that wishes to store the QString needs to assign it to a
QString, which performs a deep copy. Everyone else can work with the static-
storage string data directly (until the plugin gets unloaded, of course, but
that would be visible in the client code).
--
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
More information about the Development
mailing list