[Development] RFC: Proposal for a semi-radical change in Qt APIs taking strings
Marc Mutz
marc.mutz at kdab.com
Wed Oct 14 20:09:56 CEST 2015
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.mutz at kdab.com> | Senior Software Engineer
KDAB (Deutschland) GmbH & Co.KG, a KDAB Group Company
Tel: +49-30-521325470
KDAB - The Qt Experts
More information about the Development
mailing list