On 06/11/15 17:38, "Development on behalf of Giuseppe D'Angelo" <development-boun...@qt-project.org on behalf of dange...@gmail.com> wrote:
>On Fri, Nov 6, 2015 at 5:20 PM, Kevin Kofler <kevin.kof...@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. Cheers, Lars _______________________________________________ Development mailing list Development@qt-project.org http://lists.qt-project.org/mailman/listinfo/development
