> -----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 this. > > Qt is a framework. > It gets used in many ways. > This makes it hard to say what options clients have - or don't have. > In the end, SEP means telling some class of potential clients of Qt that Qt > has > made a design decision that means they have to use something other than Qt.
Well ... we'd 'just' have to make sure we don't "leak" QString's created by QStringLiteral across dll/plugin boundaries. Then, it's indeed the choice of the user's (say KDE) whether they want to use it in their libraries and applications, or not. 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, instead of mindlessly calling QString::fromLatin1() a million times in a row. Regards Kai _______________________________________________ Development mailing list Development@qt-project.org http://lists.qt-project.org/mailman/listinfo/development
