Re: [Development] User-defined literals for QString (and QByteArray)
On Friday, 5 March 2021 04:40:24 PST Lars Knoll wrote:
> I wish we had a good way of adding that overloaded constructor to QString.
> Unfortunately, we have lots of API that is overloaded on both QString and
> QStringView. Adding the constructor to QString will then cause ambiguities
> wherever we have overloaded API taking both a QString and a QStringView.
>
> I wish there was a way to tell the compiler to prefer one conversion over
> the other ("if you have the choice, always use QStringView and not
> QString”), but C++ doesn’t have a way to do that.
There an ugly way. By making one of the two a template function, it lowers in
priority for matching.
template
std::enable_if_t> f(const T &);
void f(QStringView);
void g()
{
f(u"Hello");
}
The problem is that changing existing QString methods to be templates is
binary incompatible. That means we can't add QStringView overloads where
QString parameters already exist and are out-of-line (remember: any non-
template method in an exported class is out of line for the purposes of BC).
Another one is to add the constructor to QString, but make it explicit. So you
can still work on char16_t literals, but you may need to wrap it on QString():
void g1()
{
f(QString(u"Hello"));
}
The problem in this one is that it's far easier to write f("Hello") than the
slightly more efficient f(QString(u"Hello")). For this, an UDL would help.
And it's really only *slightly* more efficient. Previous benchmarks have shown
that going through the UTF-8 decoder adds 2-5% loss compared to memcpy() and
that time is dwarfed anyway by the cost of allocating memory.
--
Thiago Macieira - thiago.macieira (AT) intel.com
Software Architect - Intel DPG Cloud Engineering
___
Development mailing list
Development@qt-project.org
https://lists.qt-project.org/listinfo/development
Re: [Development] User-defined literals for QString (and QByteArray)
Il 05/03/21 13:51, Andrei Golubev ha scritto: That said, QByteArray's ctor accepting char* is not explicit (which kind of makes sense) and we have this ambiguity for f(QByteArray) and f(QByteArrayView) I believe. But guessing that it's not expected that QByteArrayView would be as popular as QStringView. Sure, but this results in functions overloaded for QByteArray and const char *, not QByteArray and QByteArrayView -- see QByteArray's operators, qCompress, etc. Thus, QByteArray str = "hello" works fine, so maybe no need to introduce a UDL for that class. OTOH, QString and QByteArray would have API differences (in some sense) yet again (and there's QByteArrayLiteral). But the UDL you proposed is for the non-allocating path, so QByteArray b = "hello"_qba; is different from QByteArray b = "hello"; Cheers, -- Giuseppe D'Angelo | giuseppe.dang...@kdab.com | Senior Software Engineer KDAB (France) S.A.S., a KDAB Group company Tel. France +33 (0)4 90 84 08 53, http://www.kdab.com KDAB - The Qt, C++ and OpenGL Experts smime.p7s Description: Firma crittografica S/MIME ___ Development mailing list Development@qt-project.org https://lists.qt-project.org/listinfo/development
Re: [Development] User-defined literals for QString (and QByteArray)
That said, QByteArray's ctor accepting char* is not explicit (which kind of makes sense) and we have this ambiguity for f(QByteArray) and f(QByteArrayView) I believe. But guessing that it's not expected that QByteArrayView would be as popular as QStringView. Thus, QByteArray str = "hello" works fine, so maybe no need to introduce a UDL for that class. OTOH, QString and QByteArray would have API differences (in some sense) yet again (and there's QByteArrayLiteral). -- Best Regards, Andrei From: Development on behalf of Ville Voutilainen Sent: Friday, March 5, 2021 1:38 PM To: Giuseppe D'Angelo Cc: Qt development mailing list Subject: Re: [Development] User-defined literals for QString (and QByteArray) On Fri, 5 Mar 2021 at 14:26, Giuseppe D'Angelo via Development wrote: > > Il 05/03/21 12:08, Tor Arne Vestbø ha scritto: > > This seems like a bug though? From an API point of view, I’d expect this > > simple assignment to JustWorkTM, without requiring syntactic sugar all > > over the place. Shouldn’t we fix this, so we don’t need (or leave > > optional) an explicit _qs suffix? > > Because of > >void f(QString); >void f(QStringView); >f(u"foobar"); // ambiguous > > combined with the overarching plan of adding QStringView overloads when > possible (that is, in functions where historically we weren't doing so) > and never breaking BC/SC. Right. Somethings gotta give, and if QString and QStringView are implicitly convertible from the same things, those calls are ambiguous, and there's nothing that can be done about that unless the overload set f decides which one it prefers. Compromising the implicit convertibility would allow us to make one of those functions preferable, but that would mean that all conversions to one of those types need to be explicit. At which point the syntax you want to work doesn't work. The ambiguity doesn't prevent it from working, though - but if we don't want that ambiguity, we need to make either of QString or QStringView not-implicitly-convertible from a literal. Like in this little playground: https://wandbox.org/permlink/mjAdAI56GCjBXhjJ ___ Development mailing list Development@qt-project.org https://lists.qt-project.org/listinfo/development ___ Development mailing list Development@qt-project.org https://lists.qt-project.org/listinfo/development
Re: [Development] User-defined literals for QString (and QByteArray)
On 5 Mar 2021, at 12:08, Tor Arne Vestbø
mailto:tor.arne.ves...@qt.io>> wrote:
On 3 Mar 2021, at 16:53, Andrei Golubev
mailto:andrei.golu...@qt.io>> wrote:
QString hello = u"Hello"; // oops, compilation error
This seems like a bug though? From an API point of view, I’d expect this simple
assignment to JustWorkTM, without requiring syntactic sugar all over the place.
Shouldn’t we fix this, so we don’t need (or leave optional) an explicit _qs
suffix?
The explicit _qs suffix would basically replace QStringLiteral. We can’t have a
generic QString(char16_t *) constructor that doesn’t copy the data.
I wish we had a good way of adding that overloaded constructor to QString.
Unfortunately, we have lots of API that is overloaded on both QString and
QStringView. Adding the constructor to QString will then cause ambiguities
wherever we have overloaded API taking both a QString and a QStringView.
I wish there was a way to tell the compiler to prefer one conversion over the
other ("if you have the choice, always use QStringView and not QString”), but
C++ doesn’t have a way to do that.
Cheers,
Lars
___
Development mailing list
Development@qt-project.org
https://lists.qt-project.org/listinfo/development
Re: [Development] User-defined literals for QString (and QByteArray)
On Fri, 5 Mar 2021 at 14:26, Giuseppe D'Angelo via Development wrote: > > Il 05/03/21 12:08, Tor Arne Vestbø ha scritto: > > This seems like a bug though? From an API point of view, I’d expect this > > simple assignment to JustWorkTM, without requiring syntactic sugar all > > over the place. Shouldn’t we fix this, so we don’t need (or leave > > optional) an explicit _qs suffix? > > Because of > >void f(QString); >void f(QStringView); >f(u"foobar"); // ambiguous > > combined with the overarching plan of adding QStringView overloads when > possible (that is, in functions where historically we weren't doing so) > and never breaking BC/SC. Right. Somethings gotta give, and if QString and QStringView are implicitly convertible from the same things, those calls are ambiguous, and there's nothing that can be done about that unless the overload set f decides which one it prefers. Compromising the implicit convertibility would allow us to make one of those functions preferable, but that would mean that all conversions to one of those types need to be explicit. At which point the syntax you want to work doesn't work. The ambiguity doesn't prevent it from working, though - but if we don't want that ambiguity, we need to make either of QString or QStringView not-implicitly-convertible from a literal. Like in this little playground: https://wandbox.org/permlink/mjAdAI56GCjBXhjJ ___ Development mailing list Development@qt-project.org https://lists.qt-project.org/listinfo/development
Re: [Development] User-defined literals for QString (and QByteArray)
Il 05/03/21 12:08, Tor Arne Vestbø ha scritto: This seems like a bug though? From an API point of view, I’d expect this simple assignment to JustWorkTM, without requiring syntactic sugar all over the place. Shouldn’t we fix this, so we don’t need (or leave optional) an explicit _qs suffix? Because of void f(QString); void f(QStringView); f(u"foobar"); // ambiguous combined with the overarching plan of adding QStringView overloads when possible (that is, in functions where historically we weren't doing so) and never breaking BC/SC. HTH, -- Giuseppe D'Angelo | giuseppe.dang...@kdab.com | Senior Software Engineer KDAB (France) S.A.S., a KDAB Group company Tel. France +33 (0)4 90 84 08 53, http://www.kdab.com KDAB - The Qt, C++ and OpenGL Experts smime.p7s Description: Firma crittografica S/MIME ___ Development mailing list Development@qt-project.org https://lists.qt-project.org/listinfo/development
Re: [Development] User-defined literals for QString (and QByteArray)
On 3 Mar 2021, at 16:53, Andrei Golubev mailto:andrei.golu...@qt.io>> wrote: >> QString hello = u"Hello"; // oops, compilation error Tor Arne Vestbø (5 March 2021 12:08) replied: > This seems like a bug though? From an API point of view, I’d expect > this simple assignment to JustWorkTM, without requiring syntactic > sugar all over the place. Shouldn’t we fix this, so we don’t need (or > leave optional) an explicit _qs suffix? Suggest a fix that works ? The problem is that, when a function has overloads taking both QStringView and QString, calling the function with u"..." as parameter would then have an ambiguous choice between two signatures it can coerce that to. We could have purged the QString version of all of those at Qt 6, to avoid this, but we'd still have the problem of not being able to add QStringView overloads to other functions still taking QString during the Qt 6 lifetime. Eddy. ___ Development mailing list Development@qt-project.org https://lists.qt-project.org/listinfo/development
Re: [Development] User-defined literals for QString (and QByteArray)
On 3 Mar 2021, at 16:53, Andrei Golubev mailto:andrei.golu...@qt.io>> wrote: QString hello = u"Hello"; // oops, compilation error This seems like a bug though? From an API point of view, I’d expect this simple assignment to JustWorkTM, without requiring syntactic sugar all over the place. Shouldn’t we fix this, so we don’t need (or leave optional) an explicit _qs suffix? Tor Arne ___ Development mailing list Development@qt-project.org https://lists.qt-project.org/listinfo/development
Re: [Development] User-defined literals for QString (and QByteArray)
For anyone interested, here's a patch: https://codereview.qt-project.org/c/qt/qtbase/+/337616 -- Best Regards, Andrei From: Development on behalf of Thiago Macieira Sent: Wednesday, March 3, 2021 8:58 PM To: development@qt-project.org Subject: Re: [Development] User-defined literals for QString (and QByteArray) On Wednesday, 3 March 2021 07:53:25 PST Andrei Golubev wrote: > This is the proposal in a nutshell. I'd like to have some feedback and then > some suggestions regarding: > > * Whether we want this for QByteArray as well (similarly to QString it > allows "from raw data" construction, but then it's not really a string > class, is it?) I don't think it's necessary. That doesn't happen often enough and when it does, fromRawData is probably enough. > * What suffix to use: in the example above I used "_q", but maybe "_qs" > is better or something totally different I think _qs. > * How to call a namespace: I'd probably go with "QtLiterals" but (looking > at [2]) maybe there should be a richer hierarchy? For example, > "QtLiterals::StringLiterals", so that the suffix could be reused without > conflicts, etc. No preference. > * Whether *View classes need it (in theory they should allow implicit > construction, so probably not) No, they don't, since you can already construct them without too much typing. -- Thiago Macieira - thiago.macieira (AT) intel.com Software Architect - Intel DPG Cloud Engineering ___ Development mailing list Development@qt-project.org https://lists.qt-project.org/listinfo/development ___ Development mailing list Development@qt-project.org https://lists.qt-project.org/listinfo/development
[Development] Add QTBUG title to new release changelog
Good morning, I was curious to see what changed in Qt 6.0.2 release and found a list of fixed QTBUGS: [qtbase] 443ce5d073 Fixes: QTBUG-89578 b61275ee72 Fixes: QTBUG-90042 e255716291 Fixes: QTBUG-74088 The QTBUG number itself does not tell me much, hence it is very hard to predict if anything relevant is in that release affecting my projects. How hard would it be to change it to [qtbase] 443ce5d073 Fixes: QTBUG-89578 QLineEdit Cursor show white line when use property of setInputMask b61275ee72 Fixes: QTBUG-90042 QIcon not using Hi DPI pixmap version e255716291 Fixes: QTBUG-74088 Menu Bar Items Disabled When QMainWindow Has Window Modal Child and Another Window Made Active That would be much easier to read. Cheers Roland ___ Development mailing list Development@qt-project.org https://lists.qt-project.org/listinfo/development
