Den tors 14 maj 2020 15:46Marc Mutz via Development <
development@qt-project.org> skrev:
> On 2020-05-13 17:17, Matthew Woehlke wrote:
> [...]
> > Non-owning QString is dangerous. QStringLiteral is less dangerous
> > because it is almost never used with non-rodata storage (and indeed, I
> > would
On 2020-05-13 17:17, Matthew Woehlke wrote:
[...]
Non-owning QString is dangerous. QStringLiteral is less dangerous
because it is almost never used with non-rodata storage (and indeed, I
would consider any such usage highly suspect, if not outright broken).
QString::fromRawData is dangerous, but
On 2020-05-13 20:48, Jaroslaw Kobus wrote:
From: Development on behalf of
Thiago Macieira
Sent: Wednesday, May 13, 2020 6:21 PM
To: development@qt-project.org
Subject: Re: [Development] QString and related changes for Qt 6
On terça-feira, 12 de maio de 2020 22:57:31 PDT Jaroslaw Kobus wrote
> From: Development on behalf of Thiago
> Macieira
> Sent: Wednesday, May 13, 2020 6:21 PM
> To: development@qt-project.org
> Subject: Re: [Development] QString and related changes for Qt 6
>
> On terça-feira, 12 de maio de 2020 22:57:31 PDT Jaroslaw Kobus wrote:
> >
On terça-feira, 12 de maio de 2020 22:57:31 PDT Jaroslaw Kobus wrote:
> That's why I've mentioned the better option: aggregation: QStringView could
> be a member of QString. However, the downside would be that every time you
> want to call a const method for QString, you would need to first get
On 13/05/2020 11.49, Giuseppe D'Angelo wrote:
Il 13/05/20 16:44, Matthew Woehlke ha scritto:
Note that adding the QString(char16_t*) constructor
Pedantic, but surely you meant `char16_t const*`.
Hey, you can't nitpick here ...
This can be solved with a third overload:
template
Il 13/05/20 16:44, Matthew Woehlke ha scritto:
Note that adding the QString(char16_t*) constructor
Pedantic, but surely you meant `char16_t const*`.
Hey, you can't nitpick here ...
This can be solved with a third overload:
template
void foo(char16_t ()[N]) { foo(QStringView{s, N});
On 12/05/2020 17.21, Thiago Macieira wrote:
On Tuesday, 12 May 2020 08:42:28 PDT Matthew Woehlke wrote:
How will this work? As I understand, the main advantage to
QStringLiteral is that it statically encodes the *length* as well as the
data. This isn't possible with raw literals, which are
On 13/05/2020 02.33, Lars Knoll wrote:
On 12 May 2020, at 23:09, Thiago Macieira wrote:
I want rules that determine what the API should be without looking at the
implementation of those two functions.
You may be disappointed, at least as far as parameters.
This is one reason why I think we
On 12/05/2020 13.48, Giuseppe D'Angelo via Development wrote:
On 5/12/20 6:12 PM, Иван Комиссаров wrote:
So the question is - is it possible to allow to construct QString from
unicode literal?
"Not yet", but adding a constructor from char16_t to QString makes sense.
This creates a problem
On Wed, 13 May 2020 at 12:50, Tor Arne Vestbø wrote:
>
>
>
> > On 13 May 2020, at 10:12, Edward Welbourne wrote:
> >
> >> Note that adding the QString(char16_t*) constructor introduces this
> >> ambiguity for the functions that are already overloaded on
> >> QString+QStringView (and thus today
> On 13 May 2020, at 10:12, Edward Welbourne wrote:
>
>> Note that adding the QString(char16_t*) constructor introduces this
>> ambiguity for the functions that are already overloaded on
>> QString+QStringView (and thus today are using QStringView).
>
> Would it suffice to skip the
On Tue, May 12, 2020 at 02:09:21PM -0700, Thiago Macieira wrote:
> On Tuesday, 12 May 2020 10:48:24 PDT Giuseppe D'Angelo via Development wrote:
> > What do you do? Adding a QStringView overload will make calls ambiguous,
> > removing the QString one will be an ABI break. We need an established
>
On 5/12/20 6:12 PM, Иван Комиссаров wrote:
>> So the question is - is it possible to allow to construct QString from
>> unicode literal?
Giuseppe D'Angelo (12 May 2020 19:48) replied:
> "Not yet", but adding a constructor from char16_t to QString makes sense.
>
> This creates a problem down the
> On 12 May 2020, at 23:09, Thiago Macieira wrote:
>
> On Tuesday, 12 May 2020 10:48:24 PDT Giuseppe D'Angelo via Development wrote:
>> What do you do? Adding a QStringView overload will make calls ambiguous,
>> removing the QString one will be an ABI break. We need an established
>> solution
> On 13 May 2020, at 08:14, André Somers wrote:
>
>
> On 12-05-20 22:42, Thiago Macieira wrote:
>>
>> QStringView::mid(), for example, returns QStringView, but QString::mid()
>> returns QString.
> _Should_ QString::mid be returning a QString though? Perhaps it should return
> a QStringView?
> On 12 May 2020, at 23:21, Thiago Macieira wrote:
>
> On Tuesday, 12 May 2020 08:42:28 PDT Matthew Woehlke wrote:
>> How will this work? As I understand, the main advantage to
>> QStringLiteral is that it statically encodes the *length* as well as the
>> data. This isn't possible with raw
> On 12 May 2020, at 22:42, Thiago Macieira wrote:
>
> On Tuesday, 12 May 2020 09:34:40 PDT Marc Mutz via Development wrote:
>> On 2020-05-12 11:31, Jaroslaw Kobus wrote:
>>> So, just an idea: instead of repeating the common API part in QString
>>> and QStringView, what about making it one
On 12-05-20 22:42, Thiago Macieira wrote:
QStringView::mid(), for example, returns QStringView, but QString::mid()
returns QString.
_Should_ QString::mid be returning a QString though? Perhaps it should
return a QStringView?
André
___
Development
> From: Development on behalf of Thiago
> Macieira
> Sent: Tuesday, May 12, 2020 10:42 PM
> To: development@qt-project.org
> Subject: Re: [Development] QString and related changes for Qt 6
> > On 2020-05-12 11:31, Jaroslaw Kobus
On Tuesday, 12 May 2020 08:42:28 PDT Matthew Woehlke wrote:
> How will this work? As I understand, the main advantage to
> QStringLiteral is that it statically encodes the *length* as well as the
> data. This isn't possible with raw literals, which are merely
> NUL-terminated.
Black magic!
I
On Tuesday, 12 May 2020 10:48:24 PDT Giuseppe D'Angelo via Development wrote:
> What do you do? Adding a QStringView overload will make calls ambiguous,
> removing the QString one will be an ABI break. We need an established
> solution for these cases as they'll pop up during the Qt 6 lifetime.
On Tuesday, 12 May 2020 09:34:40 PDT Marc Mutz via Development wrote:
> On 2020-05-12 11:31, Jaroslaw Kobus wrote:
> > So, just an idea: instead of repeating the common API part in QString
> > and QStringView, what about making it one common? E.g. what about:
> > - deriving QString from
On Tuesday, 12 May 2020 02:04:35 PDT Tor Arne Vestbø wrote:
> During the contributor summit we were talking about just assuming “foo” is
> utf-8, now that our source code is utf-8. Is that not possible?
We've been doing that since 5.0.
But UTF-8 to UTF-16 requires a conversion. u"" wouldn't and
On Tuesday, 12 May 2020 02:01:45 PDT Edward Welbourne wrote:
> I largely agree, with the exception of: supporting an 8-bit string view
> type for comparisons (including startsWith(), find()/indexOf() and
> similar) can save client code a factor of two on the size of many string
> literals. I'm
On 5/12/20 6:12 PM, Иван Комиссаров wrote:
So the question is - is it possible to allow to construct QString from unicode
literal?
"Not yet", but adding a constructor from char16_t to QString makes sense.
This creates a problem down the line: today you have a
f(QString)
and you call it
On 2020-05-12 16:12, Giuseppe D'Angelo via Development wrote:
On 5/12/20 12:20 PM, Иван Комиссаров wrote:
* Exceptions can be done where significant performance gains can be
demonstrated and the API will by design not require a copy of the
data (e.g. XML writer, stream writers, date time
On 2020-05-12 11:31, Jaroslaw Kobus wrote:
So, just an idea: instead of repeating the common API part in QString
and QStringView, what about making it one common? E.g. what about:
- deriving QString from QStringView (and adding mutator API)
or (maybe even better):
- aggregating QStringView
Good question!
Personally, I think that both should accept u"foo" as input. However, the
following code does not compile:
QString s(u"foo");
I have no idea if this is intentional or not and if there will be problems with
QString/QStringView overloads.
However, since the overloads are going
On 12/05/2020 03.49, Lars Knoll wrote:
* QStringLiteral should turn into a small wrapper around u”…”, and
probably also get deprecated. Maybe we could add a user defined
literal for it instead that returns a read-only QString (QString s =
“…”_q;). So u”…” would lead to a QStringView, u”…”_q to a
On 5/12/20 12:20 PM, Иван Комиссаров wrote:
* Exceptions can be done where significant performance gains can be
demonstrated and the API will by design not require a copy of the data (e.g.
XML writer, stream writers, date time handling)
Let me disagree here. The decision should be taken on
On 2020-05-12 12:36, Lars Knoll wrote:
...
Leaving things behind simplifies our lives and in the longer term also
our users life. And yes, non unicode encodings are legacy in todays
world. They need to disappear, and most people are working towards
that goal. We can and should do our part.
> On 12 May 2020, at 11:34, André Pönitz wrote:
>
> On Tue, May 12, 2020 at 07:49:06AM +, Lars Knoll wrote:
>> I believe it’s important to leave the non Unicode world behind us [...]
>
> Is that meant to be a convincing technical argument?
This is nothing technical per se.
>
>> * We
> 12 мая 2020 г., в 09:49, Lars Knoll написал(а):
>
> Hi all,
>
First of all, the plan sounds great!
>
> Most other classes:
>
> * Only take and return QString
> * Exceptions can be done where significant performance gains can be
> demonstrated and the API will by design not require a
> On 12 May 2020, at 11:04, Tor Arne Vestbø wrote:
>
>
>> On 12 May 2020, at 09:49, Lars Knoll wrote:
>>
>> * Our QLatin1String uses are in most cases about pure ASCII strings. In any
>> case, we should consider mass porting them over to u”…” instead.
>
> During the contributor summit we
> From: Development on behalf of Lars
> Knoll
> Sent: Tuesday, May 12, 2020 9:49 AM
> To: Qt development mailing list
> Subject: [Development] QString and related changes for Qt 6
>
>
> * QStringView and QByteArrayView need to be completed to implement all const
> me
> On 12 May 2020, at 09:49, Lars Knoll wrote:
>
> * Our QLatin1String uses are in most cases about pure ASCII strings. In any
> case, we should consider mass porting them over to u”…” instead.
During the contributor summit we were talking about just assuming “foo” is
utf-8, now that our
Lars Knoll (12 May 2020 09:49) wrote:
> My high level goal for the string classes in Qt 6 was to complete the
> Unicode related changes that we started for Qt 5.0, where we made utf8
> and utf16 the main encodings, and simplify things. I believe it’s
> important to leave the non Unicode world
Hi all,
I’ve had a longer chat with Thiago about how to evolve QString for Qt 6 last
week.
Some work has already happened, so both QString and QByteArray now share the
data structure with QList/QVector, enabling zero-copy conversion between the
types. There’s also some pending changes to
39 matches
Mail list logo
