[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