[Development] Supported compilers for Qt 6

Thiago Macieira thiago.macieira at intel.com
Tue Aug 13 02:16:35 CEST 2019


On Monday, 12 August 2019 13:34:25 PDT Mutz, Marc via Development wrote:
> > QByteArray, due to its dual string / byte array nature, will continue
> > to
> > operate on char.
> 
> It was a mistake to merge QCString and QByteArray back then. This design
> doesn't work. Python 2 realized it, and we realized it too (toLower()
> interprets as L1, but const char*, and thus, by extension, QByteArray,
> is expected to be utf-8-encoded in Qt source). We had them separate
> before, we can separate them again.

Maybe it was, maybe it wasn't. But the point is that QByteArray, today, has a 
dual array / string operation and we can't remove this for 6.0. We can work 
towards something new during the 6.x lifetime and maybe undo the mistake, if 
it is a mistake, by 7.0.

We should fix some of the mistakes, like QByteArray operating on Latin 1.

> > After all, char *is* a byte.
> 
> No, a char is a character. std::byte is a byte.

std::byte is just an enum over the actual byte type, which is unsigned char. 
But by definition of byte, all three char types are bytes.

I agree we shouldn't *use* char as bytes. That's semantically confusing. But 
it is, still, a byte.

> I'm not saying it's easy to reduce QByteArray to an array of byte, but
> it's a longer-term goal we should strive for. And we can emulate
> std::byte:
> 
>     enum class QByte : unsigned char {};

Do we need to? I mean, when was std::byte added?

> Lars said "and selected C++20 features". char8_t is a game-changer for
> Qt. I don't expect we can depend on it, but this, and the other two
> (std::byte and CTAD) are, from my POV, high amongst the features that
> have the most impact on the Qt API.

Right, he did say that. But I now dispute it: we should not force our build to 
compile with -std=c++2a. See the iOS issue as an example.

I also think we currently have some modules lowering from C++17 to C++14. 
There were compatibility reasons we had to do that.

-- 
Thiago Macieira - thiago.macieira (AT) intel.com
  Software Architect - Intel System Software Products






More information about the Development mailing list