On Wednesday 14 October 2015 12:41:12 Allan Sandfeld Jensen wrote: > Why not a QCharArray? With external data constructor, that should be the > same, shouldn't it?
If you propose something like QString/QByteArray::fromRawData(), then that allocates the control block, so no, not really an option. > Anyway, I doubt this is really something that needs optimizing, QString is > neat because it is simple and easy to remember. If anything we need to > use QByteArray in more places where QStrings are only 8-bit strings. I'm not optimising. I'm decoupling the concept of a "QString" from the owning implementation "QString", so that we don't need to either convert from/to QString quite so often or you can use "foreign types" (std::basic_string<char16_t>, char16_t[], ...) in lieu of QString. That is important when you need to interface with 3rd-party libraries. Thanks, Marc -- Marc Mutz <marc.m...@kdab.com> | Senior Software Engineer KDAB (Deutschland) GmbH & Co.KG, a KDAB Group Company Tel: +49-30-521325470 KDAB - The Qt Experts _______________________________________________ Development mailing list Development@qt-project.org http://lists.qt-project.org/mailman/listinfo/development