On Friday 06 November 2015 09:47:51 Koehne Kai wrote:
> The easiest way to achieve this is to ban QStringLiteral and
> QByteArrayLiteral inside Qt's own code. Somehow I doubt that this would
> have noticeable impact anyway, at least if the replacement tries to cache
> strings once constructed, inst
On Friday 06 November 2015 16:45:33 Knoll Lars wrote:
> 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
On Friday 06 November 2015 08:52:29 Welbourne Edward wrote:
> > SEP?
>
> Sorry, reference to hitch-hiker's guide to the galaxy:
> Someone Else's Problem.
https://en.wikipedia.org/wiki/SEP_field
"... is a psychological effect where people choose to dissociate themselves
from an issue that may be
> On 06 Nov 2015, at 17:45, Knoll Lars wrote:
>
> On 06/11/15 17:38, "Development on behalf of Giuseppe D'Angelo"
> wrote:
Hi,
> 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
On 06/11/15 17:38, "Development on behalf of Giuseppe D'Angelo"
wrote:
>On Fri, Nov 6, 2015 at 5:20 PM, Kevin Kofler 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 a
On Fri, Nov 6, 2015 at 5:20 PM, Kevin Kofler 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
Thiago Macieira wrote:
> 1) Declare it SEP and only apply workarounds for the places where
> QStringLiteral is used in our plugins, suggesting that people do the same
> in their plugins.
>
> Problems: libraries loaded by plugins, fragile.
+1. Caveat emptor.
Deep copying destroys the point of QSt
> If you're willing to compile and run the attached simple C program,
> please let me know its output and your platform's details - ideally
> off-list - I'll give a summary in a few days' time.
Thanks to those who responded, I now know:
* that all the platforms below do the same thing if tm_isdst
> -Original Message-
> From: Development [mailto:development-boun...@qt-project.org] On Behalf
> [...]
> The problem with SEP is that it only works in so far as there *is* something
> the
> author of client code can do about the situation. They may not have enough
> choice to control th
> SEP?
Sorry, reference to hitch-hiker's guide to the galaxy:
Someone Else's Problem.
Eddy.
___
Development mailing list
Development@qt-project.org
http://lists.qt-project.org/mailman/listinfo/development
> -Original Message-
> From: Development [mailto:development-boun...@qt-project.org] On Behalf Of
> Thiago Macieira
> Sent: Thursday, 5 November 2015 5:45 PM
> To: development@qt-project.org
> Subject: [Development] RFD: plugins vs QStringLiterals
>
[snip]
>
> 1) Declare it SEP and only a
IIUC, the problem Thiago is discussing is a crash on exit(), or after
main() has returned. This limits the scope of the problem (we don't
make applications crashy while running), but only somewhat. There may
be things in the application loading a plugin that rely on clean
shutdown, including dest
12 matches
Mail list logo
