Marc,

It is clear that your main concern is performance (needless conversions) and 
convenience (being able to work efficiently with 3rd party libraries).
Regarding performance, I think it would be good if we could come up with some 
numbers. How 'bad' is the current implementation compared to an 'ideal' 
situation? And then define some acceptable target keeping into account 
convenience. Otherwise I am afraid that discussions can keep going forever over 
1 instruction more or less.
Regarding convenience, and that is what Qt is all about, I think you made a 
tremendous proposal that can really bring Qt a big step forward. The idea is 
very sound and clear. Of course, there are technical challenges, but that is 
what we are supposed to solve.

I also agree that we should aim for simplicity. QString and QStringView is 
simple to understand, iff we can get rid of all other string related classes. 
The ideal case would be just to have one QString class, although I doubt that 
is achievable.

I think it would be good to come up with some real-world use-cases that show 
how a Qt user and a Qt application could benefit from your proposal. 
Personally, I never experienced a performance problem with QString; but then 
the applications I write are not very string oriented. I am a QString 
aficionado :-)

After all, what I really like about Qt is convenience, simplicity and 
portability. I think this should be the main focus of Qt, and that also implies 
smooth collaboration with the outside world.

Cheers,

Kurt

> On 16 Oct 2015, at 21:47, Marc Mutz <marc.m...@kdab.com> wrote:
> 
>> On Friday 16 October 2015 19:31:50 Thiago Macieira wrote:
>> The conversion from one to the other is one instruction.
> 
> Which is one instruction too much for tail-call optimisation, e.g.
> 
> But the point was about std::string_view binary compatibility. As basically a 
> C struct with no ownership semantics, it would be a perfect vehicle to pass 
> strings around different programming languages and compilers, but only if the 
> ABI (ie. the data members) were specified.
> 
> -- 
> 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
_______________________________________________
Development mailing list
Development@qt-project.org
http://lists.qt-project.org/mailman/listinfo/development

Reply via email to