[Development] RFD: plugins vs QStringLiterals

Knoll Lars Lars.Knoll at theqtcompany.com
Fri Nov 6 17:45:33 CET 2015

On 06/11/15 17:38, "Development on behalf of Giuseppe D'Angelo" <development-bounces at qt-project.org on behalf of dangelog at gmail.com> wrote:

>On Fri, Nov 6, 2015 at 5:20 PM, Kevin Kofler <kevin.kofler at chello.at> wrote:
>> They just need to deep-copy the
>> strings they return in the plugin interface with:
>> QString(orig.constData(), orig.size())
>> if they can be QStringLiterals and are susceptible of outliving the plugin.
>Given the problem is a specific case of dangling pointers to resources
>(in the plugin) about to get destroyed... in the general case, are we
>playing it "nice" and offering a way for the plugin to clean up after
>itself, by removing any resouce it may have given out to other
>libraries which will outlive it?

Unfortunately in many ways that's pretty hard to do. QStringLiteral is only one part of the problem as others have noted. We have many other things that could potentially still be referenced when the plugin gets unloaded:

* virtual tables
* doc generated data
* metatype registrations
* string and byte array literals
* any pointers to static data that leave the scope of the plugin

To me this points strongly to opt for never unloading plugins. We can of course offer a way to force the unloading if the user does it's own stuff and knows what he's doing. But Qt should probably never unload any plugins it loads, as we do not control those and don't know whether they are safe to unload.

With that we're ok for the plugins we load. And if someone else insists on unloading something it's his problem.


More information about the Development mailing list