[Development] Why can't QString use UTF-8 internally?

[Olivier Goffart]

On Tuesday 10 February 2015 19:10:29 Matthew Woehlke wrote:
> On 2015-02-10 18:40, Marc Mutz wrote:
> > On Tuesday 10 February 2015 22:26:50 Thiago Macieira wrote:
> >> It's not insurmountable. I can think of two solutions:
> >>  1) pre-allocate enough space for the UTF-16 data (strlen(utf8) * 2), so
> >> 
> >> that  the const functions can implicitly write to the UTF-16 block when
> >> needed. Since the original UTF-8 data is constant and if there are no
> >> out-of-thin-air values, multiple threads could do this operation
> >> simultaneously safely.
> > 
> > No, they can't. The writes conflict and neither happens-before the other
> > ->
> > data race -> UB.
> 
> If I spin up a bunch of threads that do a memcpy into a common output
> buffer from a common input buffer, where the latter (input) is immutable
> (at least until all threads are done executing), do you mean that the
> contents of the output buffer after any memcpy completes are
> unpredictable? ...because that would surprise me. (Assume that all
> writes that occur in the memcpy are atomic.)

Unless it is a buffer of std::atomic, it is an undefined behavior, so not only 
the contents of the buffer is unpredictable, but anything, really.

(A sufficiently smart conforming compiler could see that you are writing at 
the same location without proper synchronization and conclude that you are not 
using threads and optimize away all the other locks)

(This is getting a bit out of topic)