On Tuesday 10 February 2015, Oswald Buddenhagen wrote: > On Wed, Feb 11, 2015 at 12:37:41AM +0400, Konstantin Ritt wrote: > > Yes, that would be an ideal solution. Unfortunately, that would also > > break a LOT of existing code. > > i was thinking of making it explicit with a smooth migration path - add > QUtf8String (basically QByteArray, but don't permit implicit conversion > to avoid encoding mistakes) and QUcs4String (and QUtf16String as an > alias for current QString - for all the windows function calls). the > main effort would be adding respective overloads to all our api. then > deprecate QString, and prune it in qt6. then maybe re-add it as an > alias for utf8string a few minor versions down. does that sound > feasible? > Maybe with C++11 we don't need QString that much anymore. Use std::string with UTF8 and std::u32string for UCS4.
For Qt6 it would be worth considering how many of our classes still makes sense. Those we want CoW semantics on would make sense, but if we don't really want that on strings, maybe every framework having its own string class is finally obsolete in C++? `Allan _______________________________________________ Development mailing list Development@qt-project.org http://lists.qt-project.org/mailman/listinfo/development