> On 15 Jan 2017, at 15:04, Robin Burchell wrote:
>
> On Fri, Jan 13, 2017, at 11:58 PM, Samuel Gaist wrote:
>> Short summary, we have three possibilities:
>> 1) Own module (and current implementation)
>> 2) One “core" module and one GUI module to separate concerns for system
>> not requiring a
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
On 31.01.2017 09:55, Michael Weghorn wrote:
[...] The links about the plans for the Qt print system that
John provided in his email [1] give some kind of overview, but are
currently not enough for me to deduce the concrete next steps that need
to be taken for the implementation.
If you (or some
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
Thank you very much for your reply.
On 2017-01-31 08:04, Andrew, Shaw wrote:
> 2) Is the Qt project interested in us working together with them
to get
> the feature implemented upstream?
I would be willing to look at the changes and review them, I am sure
there are others out there
18 matches
Mail list logo
