[Development] RFC: Proposal for a semi-radical change in Qt APIs taking strings

[Marc Mutz]

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