> On 21 Aug 2019, at 13:01, Tor Arne Vestbø <tor.arne.ves...@qt.io> wrote:
>
>
>
>> On 21 Aug 2019, at 11:50, Bogdan Vatra via Development
>> <development@qt-project.org> wrote:
>>
>> Am I the only one which finds situations silly ? Of course there are more
>> examples with the other String wrappers/functions in Qt, but I think is
>> enough
>> to show how crazy is the situation.
>
> You are not!
>
> I completely agree, and I think it’s a detriment to Qt’s promise of easy to
> use APIs that these optimised versions are not automagic and hidden behind
> the scenes, or don’t have a clear cut story for when to explicitly use.
+1. Things are getting overly complex. And in the end most people will write
less optimal code simply because they do now know which class is the best to
use in which use case. If people on this list are confused, you can be certain
that 98% of our users will not get the subtle differences.
>
>> // Even more
>> QHash<QString, QString> test;
>> test[QLatin1String("key1")] = QLatin1String("some text %1").arg(1); // wrong
>> test[QStringLiteral("key1")] = QStringLiteral("some text %1").arg(1); //
>> wrong
>> again
>> test[QLatin1String("key1")] = QStringLiteral("some text %1").arg(1); //
>> still
>> wrong
>> test[QLatin1String("key1")] = QStringLiteral("some text %1").arg(1); //
>> victory !!!
>
> This should just be test[“key”] = “value”. How do we get there?
One way would be by enforcing utf8 as source encoding for Qt based projects.
It’s a huge shame that C++ doesn’t specify the encoding of source code as
opposed to pretty much any other programming language (hell even JS got that
one right…).
So I think it might be worthwhile enforcing that for Qt 6. But it leaves the
question of what to do with QL1String.
Cheers,
Lars
_______________________________________________
Development mailing list
Development@qt-project.org
https://lists.qt-project.org/listinfo/development
