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

[Olivier Goffart]

On Tuesday 10 February 2015 23:17:21 Allan Sandfeld Jensen wrote:
> Maybe with C++11 we don't need QString that much anymore. Use std::string
> with UTF8 and std::u32string for UCS4.
> 
> For Qt6 it would be worth considering how many of our classes still makes
> sense. Those we want CoW semantics on would make sense, but if we don't
> really want that on strings, maybe every framework having its own string
> class is finally obsolete in C++?

Not as long as we have a rule stating we should not use the STL as part of our 
ABI.

This allows us to keep binary compatibility even when the STL changes. For 
example, this allow to compile Qt with GNU's libstdc++ and an application 
using LLVM's libc++ (or vice-versa). It will also let Qt be compiled with GCC 
4.9, and the application be compiled with GCC 5.0.

Indeed, imagine we had something like  QLabel::setText(std::string).
The real symbol name is something like QLabel::setText(std::basic_string<...>) 
with current libstdc++, but with libc++ or GCC5.0, it would have a different 
name due to the different namespace (something like 
QLabel::setText(std::__1::basic_string<...>))
The symbol name would be different, and not found in the binary. And even if 
the namespace was the same, we would crash because the layout might be 
different.

Of course, we can decide that using the STL containers is better and that we 
don't support binary compatibility accross different implementation of the std 
library.
But anyway, we have no reason to discuss that at this point of time and we'll 
see when Qt6 comes.

(Another thing to keep in mind is that we should probably use more of what we 
call QStringRef.  I like the llvm::StringRef for example, or 
std::experimental::string_view. And in the mean time we still don't have 
QByteArrayRef)

-- 
Olivier 

Woboq - Qt services and support - http://woboq.com - http://code.woboq.org