On Wed, Oct 14, 2015 at 06:37:19AM +0000, Knoll Lars wrote: > Agree here as well. We can’t make QString utf-8 backed without breaking > way too much code. I also don’t see the need for it. The native encoding > on Windows and Mac (Cocoa) is utf-16 as well, on Linux it’s utf-8. So no > matter which platform we’re on, we won’t avoid some conversions.
I am afraid that "the native encoding on Windows and Mac (Cocoa) is UTF-16" argument does not carry much weight in my daily work. I read/write files a lot, talk to processes/services/whatever. Almost all of that uses some 8-bit encoding, often enough something compatible with UTF-8, also on Windows and Mac. Even small fry like settings keys is usually plain English 7-bit clean. QString's UTF-16 is pretty much the antithesis of a good compromise in that area. It generates line noise in the sources and wastes cycles at runtime. > And I will strongly oppose any attempts to make QString some sort of > hybrid supporting both. The added complexity in maintaining the code base > is simply not worth it. I don't think a hybrid would be better, either. But that is not part of this RFC. I think Marc's proposal of using *View classes in interfaces has some merits. How much exactly I am unsure about. I only know that the (non-)performance of QString based interfaces has bitten me often enough to justify at least some experiments. That's why I'd like to propose the following: Since experiments within Qt proper are difficult due to the BC and SC guarantees we give and the practical impossibility to un-do additions we should simply not do it there. Instead, we could (and should) use part of Qt Creator's code base, specifically some of 'leaf' plugins (i.e. plugins with no known downstream users), to play with the idea, and develop a solid understanding of the pros and cons of the idea of using *View classes in interfaces until Qt 6 comes. The way forward could be to add e.g. 'Utils::[Q]StringView' and 'Utils::[Q]ByteArrayView' in implementation src/libs/utils and start using these in a few 'harmless' plugins. The advantages here are less restrictions due to lower compatibility guarantees, less restrictions imposed by older compilers, less harm done if the experiment fails (i.e. if the *Views turn out to not be beneficial) and generally more flexibility when e.g. comparing competing implementations. Opinions? Andre' _______________________________________________ Development mailing list Development@qt-project.org http://lists.qt-project.org/mailman/listinfo/development
