On Wed, Nov 16, 2022 at 09:50:35AM -0800, Thiago Macieira wrote:
> On Tuesday, 15 November 2022 23:50:38 PST Marc Mutz via Development wrote:
> > > in a thread-safe manner (such that if something in
> > > the same thread or another thread-safely modifies that map, the original
> > > user isn't affe
On Tue, Nov 15, 2022 at 08:07:50AM +, Marc Mutz via Development wrote:
> On 14.11.22 23:04, A. Pönitz wrote:
> >> Marc’s proposal of a Non-Owning Interface is already
> >> become manifest in QRegion::begin/end
> >>
> >> https://doc.qt.io/qt-6/qregion.html#begin
> >>
> >> allowing us to write
>
On Thursday, 17 November 2022 10:32:50 PST Elvis Stansvik wrote:
> Fermat's Last QString Vectorization Update :p
Everything is already set to Gerrit. What I haven't done is benchmark it to
confirm the theoretical runs in LLVM-MCA.
It starts at
https://codereview.qt-project.org/c/qt/qtbase/+/3869
On Thursday, 17 November 2022 10:24:35 PST Volker Hilsheimer via Development
wrote:
> > Though I am postponing the QString vectorisation update to 6.6 because I
> > don't have time to collect the benchmarks to prove I'm right before
> > feature freeze next Friday.
>
> Next Friday is the platform
Den tors 17 nov. 2022 kl 18:46 skrev Thiago Macieira
:
>
> On Thursday, 17 November 2022 02:04:54 PST Marc Mutz via Development wrote:
> > > Also, sometimes I wonder if all the work you and I do to optimise these
> > > things matter, in the end. We may save 0.5% of the CPU time, only for
> > > that
> On 17 Nov 2022, at 18:45, Thiago Macieira wrote:
>
> On Thursday, 17 November 2022 02:04:54 PST Marc Mutz via Development wrote:
>>> Also, sometimes I wonder if all the work you and I do to optimise these
>>> things matter, in the end. We may save 0.5% of the CPU time, only for
>>> that to b
On Thursday, 17 November 2022 02:04:54 PST Marc Mutz via Development wrote:
> > Also, sometimes I wonder if all the work you and I do to optimise these
> > things matter, in the end. We may save 0.5% of the CPU time, only for
> > that to be dwarfed by whatever QtGui, QtQml are doing.
>
> I hear yo
Hi Thiago,
On 16.11.22 18:50, Thiago Macieira wrote:
> On Tuesday, 15 November 2022 23:50:38 PST Marc Mutz via Development wrote:
>>> in a thread-safe manner (such that if something in
>>> the same thread or another thread-safely modifies that map, the original
>>> user isn't affected).
>>
>> The
Hi Volker,
On 14.11.22 19:00, Volker Hilsheimer wrote:
[...]
> Today, the vast majority of client code already has an owning container that
> gets passed around by copy or as const references.
There are important subsets that don't, e.g. the aforementioned
serialisation APIs and where 10%+ exec
On Tuesday, 15 November 2022 23:28:46 PST Marc Mutz via Development wrote:
> In the problematic case where a temporary container is created at the
> call site for the sole purpose of providing function arguments, it's
> specifically the dec, though, which is problematic (deref-to-zero has an
> acqu
On Tuesday, 15 November 2022 23:50:38 PST Marc Mutz via Development wrote:
> > in a thread-safe manner (such that if something in
> > the same thread or another thread-safely modifies that map, the original
> > user isn't affected).
>
> The above isn't thread-safe, it isn't even re-entrant, in the
> On 16 Nov 2022, at 09:54, Marc Mutz via Development
> wrote:
[…]
>>> But UTF-16 is sacrosanct in Qt. It's a cult. Irregardless of how many
>>> deep copies it takes to convert to and from UTF-16 from native
>>> encodings, people still worship it as god-given. It's not.
[…]
> If CoW is s
Hi Philippe,
On 15.11.22 12:50, Philippe wrote:
> On Tue, 15 Nov 2022 08:52:24 +
> Marc Mutz via Development wrote:
>> QAnyStringView, QUtf8StringView and, later, QAnyString, QUtf8String,
>> can be used to to make UTF-8 a first-class citizen in Qt.
>
> Maybe, but I see a deviation from simpl
The above isn't thread-safe, it isn't even re-entrant, in the same way
that iteration using iterators isn't. This is a known issue whenever you
hand out references, and it's nothing that violates our
const-is-thread-safe promise, otherwise
... which is why we prefer to hand out (implicitly share
That's a deep copy. A deep copy of a string is obviously more expensive
than the overhead of calling the QString ctor and dtor.
That remains to be proven. A rule of thumb for atomics is that they're
two orders of magnitude slower than a normal int. They also still act as
optimizer firewalls. Wit
HI Thiago,
On 15.11.22 17:33, Thiago Macieira wrote:
> On Tuesday, 15 November 2022 01:42:55 PST Marc Mutz via Development wrote:
>>> Returning as an iteratable interface requires that we return a proxy
>>> object, like QRegularExpressionMatch, so that the solution is
>>> thread-safe. This is neit
Hi Thiago,
On 15.11.22 17:25, Thiago Macieira wrote:
> On Tuesday, 15 November 2022 00:52:24 PST Marc Mutz via Development wrote:
>> That remains to be proven. A rule of thumb for atomics is that they're
>> two orders of magnitude slower than a normal int. They also still act as
>> optimizer firew
On Tuesday, 15 November 2022 01:42:55 PST Marc Mutz via Development wrote:
> > Returning as an iteratable interface requires that we return a proxy
> > object, like QRegularExpressionMatch, so that the solution is
> > thread-safe. This is neither simple to understand, to code, or to port
> > existi
On Tuesday, 15 November 2022 00:52:24 PST Marc Mutz via Development wrote:
> That remains to be proven. A rule of thumb for atomics is that they're
> two orders of magnitude slower than a normal int. They also still act as
> optimizer firewalls. With that rule of thumb, copying 50 char16_t's is
> f
On Monday, 14 November 2022 23:52:23 PST Marc Mutz via Development wrote:
> Unless and until we replace all QString/QStringView overload sets with a
> single QAnyStringView function (possibly accompanied by a QString
> Q_WEAK_OVERLOAD), we can't make QString implicitly convertible from
> char16_t l
On Tue, 15 Nov 2022 08:52:24 +
Marc Mutz via Development wrote:
> There's nothing inherently Qt-ish about owning containers.
Yes and no, because owning containers are part of the very "Qt-ish"
Implicit Sharing idiom, which one is _great_ for the ease of use, safety
and optimization it provid
On 14.11.22 22:17, Thiago Macieira wrote:
> On Monday, 14 November 2022 12:53:19 PST Marc Mutz via Development wrote:
>>> I don't think we will ever change return types.
>>
>> Your short interjections would be more valuable if you didn't just state
>> an opinion, but also give rationale ;-)
>
> Th
On 15.11.22 08:14, Ulf Hermann via Development wrote:
>>> So, if the method immediately converts whatever it gets to QList or
>>> QString, then there is no point in passing it a span or view.
>>
>> My point is that there _is_. Citing my blog post:
>>
>> callConsumeQStringHelloWorld():
> > [...
On 14.11.22 23:04, A. Pönitz wrote:
>> Marc’s proposal of a Non-Owning Interface is already
>> become manifest in QRegion::begin/end
>>
>> https://doc.qt.io/qt-6/qregion.html#begin
>>
>> allowing us to write
>>
>>
>> for (auto rect : region) doSomethingWith(rect);
> Yes, and that's fine [but not qu
On 15.11.22 03:32, Giuseppe D'Angelo via Development wrote:
>
> We've found a robust solution to this problem via the removed_api
> mechanism, which is going to keep the QString overload, but hide it from
> clients. (At least, I *think*.) This will make calls passing u""
> literals to keep work
So, if the method immediately converts whatever it gets to QList or
QString, then there is no point in passing it a span or view.
My point is that there _is_. Citing my blog post:
callConsumeQStringHelloWorld():
> [...]
That's the worst case scenario of passing an 8bit string literal to a
On Monday, 14 November 2022 18:32:36 PST Giuseppe D'Angelo via Development
wrote:
> I'm not sure what is meant here. I was just pointing out that
> overloading a function with QString and QStringView (or QAnyStringView
> for that matter) is just a historical accident:
>
> * we have an "old" API t
Il 10/11/22 20:27, Thiago Macieira ha scritto:
(We end up with these overload sets because right now we have tons of
f(QString), and we're slowly moving them to f(QStringView) if it does
make sense for them. Due to the BC promise we can't just_remove_
f(QString).)
And we shouldn't. So we shouldn
On Mon, Nov 14, 2022 at 04:54:20PM +, Volker Hilsheimer wrote:
>
> > On 12 Nov 2022, at 14:41, A. Pönitz wrote:
> >
> > On Fri, Nov 11, 2022 at 09:35:27AM +0100, Ulf Hermann via
> > Development wrote:
> >> There is an undeniable benefit of _offering_ QSpan, QStringView,
> >> and generator AP
On Monday, 14 November 2022 12:53:19 PST Marc Mutz via Development wrote:
> > I don't think we will ever change return types.
>
> Your short interjections would be more valuable if you didn't just state
> an opinion, but also give rationale ;-)
That's why I said "I think".
We can't return a non-
On 14.11.22 18:11, Thiago Macieira wrote:
> On Monday, 14 November 2022 08:22:44 PST Marc Mutz via Development wrote:
>> Can we agree that NOI for setters is a no-brainer? Then 90% of the
>> usefulness of NOI can already be reaped, in a BC and SC manner. There's
>> pretty little we can do with retu
> On 14 Nov 2022, at 18:30, Marc Mutz via Development
> wrote:
>
> Hi Ulf,
>
> On 14.11.22 17:37, Ulf Hermann via Development wrote:
>> Hi Marc,
>>
>>> On 11.11.22 09:35, Ulf Hermann via Development wrote:
There is an undeniable benefit of _offering_ QSpan, QStringView, and
generat
Hi Ulf,
On 14.11.22 17:37, Ulf Hermann via Development wrote:
> Hi Marc,
>
>> On 11.11.22 09:35, Ulf Hermann via Development wrote:
>>> There is an undeniable benefit of _offering_ QSpan, QStringView, and
>>> generator APIs in a few relevant cases:
>>>
>>> 1. Users want to pass a "foreign" contai
On Monday, 14 November 2022 08:22:44 PST Marc Mutz via Development wrote:
> Can we agree that NOI for setters is a no-brainer? Then 90% of the
> usefulness of NOI can already be reaped, in a BC and SC manner. There's
> pretty little we can do with return values before Qt 7, except use the
> stuff i
> On 12 Nov 2022, at 14:41, A. Pönitz wrote:
>
> On Fri, Nov 11, 2022 at 09:35:27AM +0100, Ulf Hermann via Development wrote:
>> There is an undeniable benefit of _offering_ QSpan, QStringView, and
>> generator APIs in a few relevant cases:
>
> This is true, but my problem with this is that alr
Hi Marc,
On 11.11.22 09:35, Ulf Hermann via Development wrote:
There is an undeniable benefit of _offering_ QSpan, QStringView, and
generator APIs in a few relevant cases:
1. Users want to pass a "foreign" container to a Qt function that
doesn't only store it as QList or QString. It might mere
Hi Ulf,
On 11.11.22 09:35, Ulf Hermann via Development wrote:
> There is an undeniable benefit of _offering_ QSpan, QStringView, and
> generator APIs in a few relevant cases:
>
> 1. Users want to pass a "foreign" container to a Qt function that
> doesn't only store it as QList or QString. It mi
> 1. Use overloads for methods that take views or spans. In new API we can
> omit the methods that take owning containers. If the overload set grows
> out of hand, don't add the view/span alternative until we can remove
> something. By Thiago's argument, that means not to convert existing
> methods
On Fri, Nov 11, 2022 at 09:35:27AM +0100, Ulf Hermann via Development wrote:
> There is an undeniable benefit of _offering_ QSpan, QStringView, and
> generator APIs in a few relevant cases:
This is true, but my problem with this is that already _offering_
additional solutions does not come for fre
There is an undeniable benefit of _offering_ QSpan, QStringView, and
generator APIs in a few relevant cases:
1. Users want to pass a "foreign" container to a Qt function that
doesn't only store it as QList or QString. It might merely iterate it or
store it as something else.
2. Assume a cont
On Thu, Nov 10, 2022 at 03:55:39PM +, Marc Mutz via Development wrote:
> Hi Ivan,
>
> On 10.11.22 11:03, Ivan Solovev via Development wrote:
> > I wonder how your NOI-everywhere suggestion will work with the
> > signal/slot connections? Specially for the case when
> > Qt::QueuedConnection is
[
TL;DR :
Qt API should use
QString foo() const;
void setFoo(const QString &);
Neither QStringView nor C++20 changes this.
]
On Wed, Nov 09, 2022 at 10:52:15AM +, Marc Mutz via Development wrote:
> Hi Ulf,
>
> On 09.11.22 08:18, Ulf Hermann via Development wrote:
> >> I don't wa
On Thursday, 10 November 2022 10:40:35 PST Giuseppe D'Angelo via Development
wrote:
> On 09/11/2022 20:25, Thiago Macieira wrote:
> > Our API should default to passing QStrings for simplicity and not to
> > confuse>
> > the user. The fact that I cannot wrote:
> >foo(u"bar');
> >
> > if foo t
On 09/11/2022 20:25, Thiago Macieira wrote:
Our API should default to passing QStrings for simplicity and not to confuse
the user. The fact that I cannot wrote:
foo(u"bar');
if foo takes a QString is MESSED UP.
Is this because we deliberately didn't add a QString(const char16_t *)
constr
> 1. It doesn't, obviously. If you emit signals, any signal argument must
>be owning, or QueuedConnection cannot be used. Given that C++20
>requires us to mark up views and non-owning ranges (enable_view,
>enable_borrowed_range), I'm confident that we could detect attempts
>to creat
Hi Ivan,
On 10.11.22 11:03, Ivan Solovev via Development wrote:
> I wonder how your NOI-everywhere suggestion will work with the
> signal/slot connections? Specially for the case when
> Qt::QueuedConnection is used (explicitly or implicitly).
That's a very good question, thanks.
As a first rea
Hi Marc,
>> I would like to know how that is supposed to work in practice. We have a
>> lot of public API dealing with Qt containers all over. What are you
>> going to do to, for example, to
>>
>> void addActions(const QList &actions);
>>
>> in qwidget.h? What should it look like when we're d
A. Pönitz wrote:
> [And since we are at it: It would ease my life (but possibly hamper the
> life of my cardiologist) if you wouldn't call it "Qt NIH API". This is
> an open insult to people who actively designed these APIs _with
> different goals_ than the STL. I personally think it's completely f
On Wednesday, 9 November 2022 11:25:32 PST Thiago Macieira wrote:
> On Wednesday, 9 November 2022 02:52:15 PST Marc Mutz via Development wrote:
> > We can also return spans:
> > QSpan actions() const;
>
> we CANNOT and MUST NOT.
Unless you can find a way to return the collection of QActions
On Wednesday, 9 November 2022 02:52:15 PST Marc Mutz via Development wrote:
> This is the same effect we have with Q*StringView, incl. avoidance of
> caller-side construction and destruction of owning containers.
Indeed, which is WRONG.
Our API should default to passing QStrings for simplicity an
On Wednesday, 9 November 2022 02:52:15 PST Marc Mutz via Development wrote:
> We can also return spans:
>
> QSpan actions() const;
we CANNOT and MUST NOT.
--
Thiago Macieira - thiago.macieira (AT) intel.com
Cloud Software Architect - Intel DCAI Cloud Engineering
___
Hi,
let me mention that I've been pondering all that hairy stuff just
recently when trying to come up with a solution for how to map QList*> and QQmlListProperty to each other without exposing people to
dangling references and without copying and allocating all the time.
One thing we could do
> On 9 Nov 2022, at 12:49, Marc Mutz via Development
> wrote:
>
> Hi Volker,
>
> On 09.11.22 10:15, Volker Hilsheimer wrote:
>> But I do believe that we can add APIs that are iterator and ranges friendly
>> to Qt without tossing out the baby with the bathwater and without breaking
>> tons o
Hi Volker,
On 09.11.22 10:15, Volker Hilsheimer wrote:
> But I do believe that we can add APIs that are iterator and ranges friendly
> to Qt without tossing out the baby with the bathwater and without breaking
> tons of code and patterns. For APIs where we simply return a stored QList we
> want
Hi Ulf,
On 09.11.22 08:18, Ulf Hermann via Development wrote:
>> I don't want to take the Qt containers away from Qt users. I want to get
>> rid of their use in our APIs, so that both the Qt implementation as well
>> as our users are free to choose the best container for their needs
>> instead of
> Volker Hilsheimer via Development wrote:
nice pragmatic overview :)
Philippe
On Wed, 9 Nov 2022 09:15:16 +
Volker Hilsheimer via Development wrote:
> Hi,
>
> > On 8 Nov 2022, at 22:20, Marc Mutz via Development
> > wrote:
> > To summarize:
> > - I will not accept responsibility for a
Hi,
> On 8 Nov 2022, at 22:20, Marc Mutz via Development
> wrote:
> To summarize:
> - I will not accept responsibility for any container rewrites in any of
> the Qt major version changes. I was not involved in any of these
> decisions, and where I was involved in the discussion, my suggestio
I don't want to take the Qt containers away from Qt users. I want to get
rid of their use in our APIs, so that both the Qt implementation as well
as our users are free to choose the best container for their needs
instead of having to pick from one of the public Qt containers.
I would like to kno
Hi Andre,
When you say
> You, /personally/ /you/, have been the driving force
I think you and Kevin are giving me credit where none is due. The Qt
containers changed multiple times before the Qt project was even formed
and yours truly could have possibly had any influence on their design.
In
On Mon, Nov 07, 2022 at 08:15:58PM +, Marc Mutz via Development wrote:
> Hi all,
>
> SCNR taking the proffered bait:
>
> On 07.11.22 18:51, Edward Welbourne wrote:
> > For Qt to remain relevant in the rapidly-evolving C++ landscape, it
> > needs to change; but one of its strong selling-points
--
Alex
> -Original Message-
> From: Development On Behalf Of
> Volker Hilsheimer via Development
> Sent: Monday, 7 November 2022 16:51
> To: Marc Mutz ; development@qt-project.org
> Subject: Re: [Development] How qAsConst and qExchange lead to qNN
>
> > On
Marc Mutz via Development wrote:
> Sure, a trivial QWidgets program from the mid-90s may still compile and
> work in Qt 6, but as soon as said program touches Qt container classes,
> it's game over.
A lot of the changes to Qt container classes were either driven by you or at
least praised by you,
Hi all,
SCNR taking the proffered bait:
On 07.11.22 18:51, Edward Welbourne wrote:
> For Qt to remain relevant in the rapidly-evolving C++ landscape, it
> needs to change; but one of its strong selling-points has long been its
> conservatism in API and ABI, that lets working code keep working.
I
Volker Hilsheimer (7 November 2022 16:51) wrote:
> The open question is whether and when we should deprecate such a
> stop-gap 1:1 reimplementations of std functionality. How to deprecate
> is now well documented, but the wiki starts with the process of doing
> so once we concluded that we shall. I
> On 4 Nov 2022, at 16:00, Marc Mutz via Development
> wrote:
>
> Hi,
>
> After getting my head washed by Volker, lemme provide background on
> these two functions.
Thanks for the context, Marc!
> TL;DR: we created real maintenance and porting problems by not removing
> stop-gap functionali
Hi,
After getting my head washed by Volker, lemme provide background on
these two functions.
TL;DR: we created real maintenance and porting problems by not removing
stop-gap functionality in a timely fashion, qNN presented as a way to
ensure this won't happen again.
Both qAsConst and qExchang
66 matches
Mail list logo
