Em quinta-feira, 2 de março de 2017, às 14:36:55 PST, Giuseppe D'Angelo
escreveu:
> Can we start these discussions, like, now? Could you please share your
> QString/QVector branch and describe what you did in there and what you
> think QString should look like in Qt 6? (Similarly, we should start
Il 20/02/2017 22:02, Thiago Macieira ha scritto:
> I really want QStringView and I'd like to talk to you how Qt6 QString,
> QStringView and a non-sharing QString class should cooperate to reduce code
> size in QtCore. Something like QString deriving from QStringView.
Can we start these discussio
On segunda-feira, 20 de fevereiro de 2017 12:48:50 PST Marc Mutz wrote:
> On Tuesday 31 January 2017 13:32:03 Lars, Knoll wrote:
> > Let's get this into dev as soon as we can, and make sure we have a great
> > story to tell for 5.10.
>
> The base commit isn't in, yet. There's been no measureable f
On Tuesday 31 January 2017 13:32:03 Lars, Knoll wrote:
> Let's get this into dev as soon as we can, and make sure we have a great
> story to tell for 5.10.
The base commit isn't in, yet. There's been no measureable forward progress
regarding review. I'm not going to work on the patch series until
Em terça-feira, 7 de fevereiro de 2017, às 20:06:38 PST, Konstantin Tokarev
escreveu:
> 07.02.2017, 20:03, "Vincas Dargis" :
> > 2017.02.06 18:38, Thiago Macieira rašė:
> >> Yes, but it's very hard to measure. I do agree in shrinking our code
> >> however much we can (which is why I'd like to sup
07.02.2017, 20:03, "Vincas Dargis" :
> 2017.02.06 18:38, Thiago Macieira rašė:
>> Yes, but it's very hard to measure. I do agree in shrinking our code however
>> much we can (which is why I'd like to suppress the unwind tables
>> completely).
>
> Sorry for off-topic, but I wonder, have anyone
2017.02.06 18:38, Thiago Macieira rašė:
Yes, but it's very hard to measure. I do agree in shrinking our code however
much we can (which is why I'd like to suppress the unwind tables completely).
Sorry for off-topic, but I wonder, have anyone measured how Qt modules
sizes differs with and with
On segunda-feira, 6 de fevereiro de 2017 10:33:52 PST Edward Welbourne wrote:
> Thiago Macieira (3 February 2017 17:45)
>
> > It's irrelevant when the function called is one of ours, in a library
> > of ours that got compiled with -fno-exceptions. It'll never
> > throw. Even the few libraries we c
>>> [followed by exception handling code irrelevant for us]
>>
>> I disagree. The exception code is not irrelevant for our users (and
>> not for us, either, e.g. in QtCore).
Thiago Macieira (3 February 2017 17:45)
> It's irrelevant when the function called is one of ours, in a library
> of ours th
On sexta-feira, 3 de fevereiro de 2017 13:48:46 PST Kevin Kofler wrote:
> The overhead compared to using QString will be reduced, but only part of it
> (the avoided memory allocation) is really an optimization. The rest of the
> "reduced" overhead is because QString will get the same overhead bloat
On sexta-feira, 3 de fevereiro de 2017 12:59:19 PST Marc Mutz wrote:
> QStringLiteral is not what most people use. It's too verbose. They use
> "&OK", cf. our tests and, to a lesser extend, because we encourage tr()
> there, examples and docs.
>
> u"&OK", however, has almost no readbility overhead
Op 03/02/2017 om 14:27 schreef Giuseppe D'Angelo:
Il 03/02/2017 13:48, Kevin Kofler ha scritto:
We really need a plan to deprecate implicit casts between QString and ASCII.
They are not only the source of such inefficiencies from inexperienced or
lazy programmers, but also of encoding-related
Il 03/02/2017 13:48, Kevin Kofler ha scritto:
> We really need a plan to deprecate implicit casts between QString and ASCII.
> They are not only the source of such inefficiencies from inexperienced or
> lazy programmers, but also of encoding-related bugs. If you need to convert
> between 8-bit e
Marc Mutz wrote:
> QStringLiteral is not what most people use. It's too verbose.
#define U(x) QStringLiteral(x)
or some other 1-letter macro or even $ (which most compilers will let you
get away with).
> They use "&OK",
We really need a plan to deprecate implicit casts between QString and ASCII
On Friday 03 February 2017 09:29:22 Thiago Macieira wrote:
> On sexta-feira, 3 de fevereiro de 2017 08:49:24 PST Marc Mutz wrote:
> > When the QString overload is replaced by a QStringView one, these calls
> > become errors. I don't mean to say that's a good thing going forward into
> > Qt 6, but I
Marc Mutz wrote:
> setLabelQStringCRef("&OK");
That is an unfair comparison. The QString code should use QStringLiteral. Of
course converting from 8-bit to 16-bit is horribly inefficient compared to
just using a 16-bit literal.
Kevin Kofler
_
On Freitag, 3. Februar 2017 10:59:21 CET Kevin Kofler wrote:
> Marc Mutz wrote:
> > The question of whether to replace QString sink arguments with QStringView
> > ones is an open one. It does not affect the usefulness of QStringView as a
> > way to pass UTF-16 data from a wide variety of sources th
Marc Mutz wrote:
> The question of whether to replace QString sink arguments with QStringView
> ones is an open one. It does not affect the usefulness of QStringView as a
> way to pass UTF-16 data from a wide variety of sources through a single
> function.
>
> I'd invite you to look at the QColor
On sexta-feira, 3 de fevereiro de 2017 08:49:24 PST Marc Mutz wrote:
> When the QString overload is replaced by a QStringView one, these calls
> become errors. I don't mean to say that's a good thing going forward into
> Qt 6, but I do say that having this option (and nothing more is being
> discus
On Friday 03 February 2017 08:49:24 Marc Mutz wrote:
> Results on GCC 6.1.1, compiled with the same settings as our tests:
Better-formatted version posted in comment to
https://codereview.qt-project.org/143763
--
Marc Mutz | Senior Software Engineer
KDAB (Deutschland) GmbH & Co.KG, a KDAB Group
On Friday 03 February 2017 08:00:16 Philippe wrote:
> On Thu, 02 Feb 2017 23:52:26 +0100
>
> Kevin Kofler wrote:
> > > On Tuesday 31 January 2017 15:24:18 Philippe wrote:
> > >> I just want to highlight, that QStringView is not COW friendly. AFAIK.
> >
> > That alone makes it actually a pessimiz
On Thu, 02 Feb 2017 23:52:26 +0100
Kevin Kofler wrote:
> > On Tuesday 31 January 2017 15:24:18 Philippe wrote:
> >> I just want to highlight, that QStringView is not COW friendly. AFAIK.
>
> That alone makes it actually a pessimization.
This is why Thiago commented with:
>But we still have to
On Thursday 02 February 2017 23:52:26 Kevin Kofler wrote:
> > But that's why we'll have QStringView Level 3, where only the QStringView
> > QLabel::setText() overload will be compiled in. Then, we compile Qt with
> > either level and check the respective performance of the result. I'll
> > wager th
> On Tuesday 31 January 2017 15:24:18 Philippe wrote:
>> I just want to highlight, that QStringView is not COW friendly. AFAIK.
That alone makes it actually a pessimization.
Marc Mutz wrote:
> Q6String will likely have the small-string optimisation, so short strings
> aren't actually COWed, but d
Alexander Volkov wrote:
> Currently it reads into QString as in a buffer and if you need to copy
> the buffer, then you
> have to manually make a deep copy of it:
> QTextStream ts(...);
> QString line;
> line.reserve(1024);
> QStringList found;
> while (ts.readLineInto(&lin
Em quarta-feira, 1 de fevereiro de 2017, às 18:09:17 PST, Александр Волков
escreveu:
> But when readLineInto() is trying to write into an implicitly shared
> string buffer,
> then the content of the buffer is copied and readLineInto() writes into
> the copy.
And that is the problem. If you're usi
01.02.2017 17:22, Marc Mutz пишет:
Ah, nevermind, 'found' is a QString_List_.
I'm curious how a non-implicitly-shared string type would help you there,
though. You can always clear() (or, in case of QVector, std::move())
the string, and capacity is left with the sole owner in the container.
On Wednesday 01 February 2017 15:20:02 Marc Mutz wrote:
> On Wednesday 01 February 2017 10:53:45 Alexander Volkov wrote:
> > found.append(QString(line.constData(), line.size())); // deep
> > copy
>
> Ummm..
>
> found.append(line.constData(), line.size());
>
> Problem solved?
On Wednesday 01 February 2017 10:53:45 Alexander Volkov wrote:
> found.append(QString(line.constData(), line.size())); // deep copy
Ummm..
found.append(line.constData(), line.size());
Problem solved?
--
Marc Mutz | Senior Software Engineer
KDAB (Deutschland) GmbH & Co.KG, a KDAB Gr
31.01.2017 21:52, Thiago Macieira пишет:
Good point, that's a point in favour of having Q{String,ByteArray}View.
We need to think how that will work with having classes for exclusive
ownership (not implicitly shared). That's the counterpart of the Views: they
don't own, but they only have read-o
On terça-feira, 31 de janeiro de 2017 18:53:55 PST Marc Mutz wrote:
> > There's an interesting advanage for using QStringView on data alloated by
> > CoreFramework / Cocoa or by Win32, but since we don't own the data, we
> > have
> > to be very careful. In fact, unlike everything else in Qt, QStrin
On terça-feira, 31 de janeiro de 2017 18:39:43 PST Marc Mutz wrote:
> Q6String will likely have the small-string optimisation, so short strings
> aren't actually COWed, but deep-copied. Passing through QStringView then is
> about the same efficiency as passing through a const QString&.
Not sure yo
On Tuesday 31 January 2017 15:24:18 Philippe wrote:
> For instance, a method such as:
>
> QLabel::setText(...)
>
> stores the passed argument somewhere. A malloc will be needed if
> QStringView is the interface and a QString the passed argument.
>
> Ok, this example is not a performance critical
On Tuesday 31 January 2017 16:18:59 Thiago Macieira wrote:
> Em terça-feira, 31 de janeiro de 2017, às 12:07:52 PST, Marc Mutz escreveu:
> > No, this is not at all about performance. It's mostly about stream-lining
> > the API, and adding flexibility:
> >
> > 1. Traditionally, a lot of stuff has b
Em terça-feira, 31 de janeiro de 2017, às 12:07:52 PST, Marc Mutz escreveu:
> No, this is not at all about performance. It's mostly about stream-lining
> the API, and adding flexibility:
>
> 1. Traditionally, a lot of stuff has been taking QString, and QString only.
> If you're lucky, you get (QCh
For instance, a method such as:
QLabel::setText(...)
stores the passed argument somewhere. A malloc will be needed if
QStringView is the interface and a QString the passed argument.
Ok, this example is not a performance critical case.
I just want to highlight, that QStringView is not COW friend
On 2017-01-31 12:50, Philippe wrote:
As far as I understand, I see a performance regression with
QStringView, for all the cases where copy-on-write can't take place
any longer.
In the following code, an extra malloc is needed. Or am I wrong?
void bar()
{
QString s("hello");
foo(s
As far as I understand, I see a performance regression with QStringView, for
all the cases where copy-on-write can't take place any longer.
In the following code, an extra malloc is needed. Or am I wrong?
void bar()
{
QString s("hello");
foo(s)
}
void foo(QStringView sv)
{
On Tuesday 31 January 2017 13:32:03 Lars, Knoll wrote:
> As much as I love getting new features in, I have to agree here.
>
> Let's get this into dev as soon as we can, and make sure we have a great
> story to tell for 5.10.
Ok, then. I'll rewrite the series to \since 5.10.
--
Marc Mutz | Seni
As much as I love getting new features in, I have to agree here.
Let's get this into dev as soon as we can, and make sure we have a great story
to tell for 5.10.
Cheers,
Lars
> On 31 Jan 2017, at 12:47, Andy, Nichols wrote:
>
> While QStringView looks like a nice addition to Qt, I don’t thin
While QStringView looks like a nice addition to Qt, I don’t think we should
risk delaying the next release over it. It is bad enough there is always a
rush to cram things in the week leading up to the release and even worse when
we start talking about extensions. If we are going to have time b
On Tuesday 31 January 2017 10:55:52 Иван Комиссаров wrote:
> What about toInt/toDouble/etc, toLower/toUpper, right/left/mid (aka
> std::string_view::remove_prefix/suffix), find and other QString methods
> that doesn't modify the string? Do you plan to add them later or support
> only small subset o
Hi Lars,
On Tuesday 31 January 2017 10:08:35 Lars, Knoll wrote:
[...]
> > So, in order to give the maintainers more time for review, I'd like to
> > ask for a feature freeze extension for QStringView until end of next
> > week, plus a few days to deal with maintainer review comments.
>
> I unders
Great job!
What about QByteArrayView? Do you plan to use std::string_view instead?
What about toInt/toDouble/etc, toLower/toUpper, right/left/mid (aka
std::string_view::remove_prefix/suffix), find and other QString methods
that doesn't modify the string? Do you plan to add them later or support
onl
Hi Marc,
The downside of any exceptions to the feature freeze (as we've seen before) is
added risk to our schedules. We should use this sparingly (and I've been
probably giving exceptions too often in the past).
> On 30 Jan 2017, at 20:03, Marc Mutz wrote:
>
> QStringView is ready to be merge
Hi,
QStringView is ready to be merged, but the maintainer has asked for another
week before he can properly review the class.
In case you don't remember, here's the discussion thread from 2015:
http://lists.qt-project.org/pipermail/development/2015-October/023358.html
Here's the evolving patch
46 matches
Mail list logo
