+1
Disclaimer: I used to be in Ievgenii's team.
--
Best Regards,
Andrei
From: Development on behalf of Mårten
Nordheim
Sent: Wednesday, April 6, 2022 3:32 PM
To: Alex Blasche ; development@qt-project.org
Subject: Re: [Development] Nominating Ievgenii Meshcher
+1!
--
Best Regards,
Andrei
From: Development on behalf of Topi Reiniö
Sent: Tuesday, February 1, 2022 8:18 AM
To: Paul Wicking ; development@qt-project.org
Subject: Re: [Development] Nominating Luca Di Sera as approver
+1. Luca has already been an invaluable
+1. Thought he is an approver already.
--
Best Regards,
Andrei
From: Development on behalf of Lars Knoll
Sent: Thursday, January 20, 2022 9:14 AM
To: Jukka Jokiniva
Cc: Qt development mailing list
Subject: Re: [Development] Nominating Dimitrios "Jimis" Apostol
+1 from me as well. While I haven't interacted with qt5compat much, I trust
Sona. She also, evidently, did significant contributions to that module.
Disclaimer: we used to be on the same team.
--
Best Regards,
Andrei
From: Development on behalf of Kevin
Kofler
Hi,
I would like to request a feature freeze exception for adding important
implementation bits of the QML type compiler (QTBUG-84368) planned to be
introduced to public in 6.3.
This compiler exists as a tool in qtdeclarative repository already, with a small
subset of tests and functionality. It
Hi,
+1.
--
Best Regards,
Andrei
From: Development on behalf of Max
Goldstein
Sent: Tuesday, August 10, 2021 2:28 PM
To: development@qt-project.org
Subject: Re: [Development] Nominating Craig Scott as approver
It's a +1 from me as well.
Best,
Max
___
Hi,
+1 from me as well.
--
Best Regards,
Andrei
From: Development on behalf of Alexandru
Croitor
Sent: Tuesday, August 10, 2021 10:19 AM
To: Joerg Bornemann
Cc: development@qt-project.org
Subject: Re: [Development] Nominating Alexey Edelev as approver
Hi,
+
+1.
Indeed, Andreas does a great job daily.
--
Best Regards,
Andrei
From: Development on behalf of Fabian
Kosmale
Sent: Thursday, April 29, 2021 8:29 AM
To: Paul Wicking ; development
Subject: Re: [Development] Nominating Andreas Buhr as approver
+1
Andreas
: [Development] Nominating Andrei Golubev as Approver
Congratulations to Andrei, approver status has been granted.
--
Alex
From: Edward Welbourne
Sent: Friday, 9 April 2021 14:07
To: Alex Blasche
Subject: Re: Nominating Andrei Golubev as Approver
On Thursday
> Is there a way to generate compile-time warnings for_enum values_?
Yes, Q_DECL_ENUMERATOR_DEPRECATED and similar.
The latest version of Q_DECL_DEPRECATED and friends should also work. I recall
it got changed to use [[deprecated]] C++ attribute, which should support enum
value case.
--
Best R
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
pment] 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
Hello,
I've been now working for a while with literals that have to (eventually) be
converted to QString one way or another. While in certain cases (e.g. myMsg ==
u"This is my message" or u"Hello, " + world) character literals are handled
neatly by some underlying machinery, pure assignments ju
Hi Evgeny,
I remember having some issues with git/gerrit process after messing with
emails, etc. (still not sure what the issue was, to be honest).
As Alex mentions, it's better if you could attach an error message or something
of the kind - right now it's not even clear whether it's git side o
I'd stay away from classification using std:: type traits, as we want
something that cannot automatically be inferred from compilers:
in the general case, a compiler cannot know that default construction =
memset to 0 (e.g. out of line constructor); and certainly they cannot
know about relocatabili
Hello,
There's another subtle case when your type has in-class member initializers -
or whatever the name is - thus it's not primitive but it really could/should be
and you want it to be: https://gcc.godbolt.org/z/3TP83f. This is something I
accidentally discovered.
And I don't think that comp
Tend to agree with Ville, it would be easier to adopt std::partial_ordering
with a proper class in place.
Also, you can use std::optional internally in that class as an underlying
storage for the result or/and have a conversion operator to std::optional
if this is a much desired return type, rig
The "flag" is basically "a call to reserve was made"? How do I clear the flag?
shrink_to_fit()/squeeze() do this along the way.
--
Best Regards,
Andrei
From: Ville Voutilainen
Sent: Thursday, September 10, 2020 4:38 PM
To: Andrei Golubev
nen
Sent: Thursday, September 10, 2020 3:43 PM
To: Andrei Golubev
Cc: development@qt-project.org
Subject: Re: [Development] Important recent changes in QList/QString/QByteArray
On Thu, 10 Sep 2020 at 11:46, Andrei Golubev wrote:
>
> That's interesting. So the container remembers what sor
development@qt-project.org
Subject: Re: [Development] Important recent changes in QList/QString/QByteArray
Il 10/09/20 08:48, Andrei Golubev ha scritto:
>
> That's the dilemma that Andrei was talking about. Either solution is
> valid and
> both have a way for you to tell Q
obligation. Consequently, QList's shrinking erase also does
not shrink when capacity is reserved.
--
Best Regards,
Andrei
From: Ville Voutilainen
Sent: Thursday, September 10, 2020 10:39 AM
To: Andrei Golubev
Cc: development@qt-project.org
Subject: Re: [Development] I
t/QString/QByteArray
On Wednesday, 9 September 2020 06:38:01 PDT Andrei Golubev wrote:
> > I don't understand what this means. Am I supposed to reserve a
> > container to its current size before erasing elements
> > from it, if I don't want the erase to shrink it?
>
20 4:20 PM
To: Andrei Golubev
Cc: development@qt-project.org
Subject: Re: [Development] Important recent changes in QList/QString/QByteArray
On Wed, 9 Sep 2020 at 11:58, Andrei Golubev wrote:
> On the other hand, "please do not free memory, I still need it" use-case is
> also j
Angelo via Development
Sent: Wednesday, September 9, 2020 12:17 PM
To: development@qt-project.org
Subject: Re: [Development] Important recent changes in QList/QString/QByteArray
On 09/09/2020 10:55, Andrei Golubev wrote:
> Small update on QList::erase: the iterator invalidation model will be
> aligned
__
From: Development
mailto:development-boun...@qt-project.org>>
on behalf of Giuseppe D'Angelo via Development
mailto:development@qt-project.org>>
Sent: Wednesday, September 2, 2020 9:37 PM
To: Andrei Golubev;
development@qt-project.org<mailto:develop
Regards,
Andrei
From: Development on behalf of Giuseppe
D'Angelo via Development
Sent: Wednesday, September 2, 2020 8:21 PM
To: development@qt-project.org
Subject: Re: [Development] Important recent changes in QList/QString/QByteArray
Il 02/09/20 17:38, Andre
I thought QVector and the older QList could decide that the container's
allocated space was too big compared to the the number of elements and
reallocate on erase() too. This doesn't seem like a new requirement.
Actually, this is something not done in Qt 5.15 as far as I can see: QList does
not se
With this setup, one might be tempted to optimize erasure in the first
half of the container by shifting elements towards the end (rather than
from the end towards the beginning), as it would be cheaper. I guess
that's what's happening here?
Yes, this is what's happening now. But I am considering
;exceptions should be documented. Please do not assume any specific behavior
>otherwise.
This seems like a potentially quite significant compatibility break,
that chopping a vector invalidates all references
and iterators to parts of the vector that the chopping didn't touch before.
--
Hello,
Let me try to improve the wording from the original mail and clarify certain
things. Sorry for not being pedantic enough at the beginning.
"Non-detaching non-const modifying operations" mean non-detaching non-const
member functions of the QCCs*, sorry for ambiguation.
*Qt Contiguous Con
Hello all,
Over the last week I pushed several patches to enable prepend optimization in
some core containers, namely, QList, QString, QByteArray.
In the light of these changes, there may occur new subtle issues in your code.
New model
---
In a nutshell, prepend optimization code does some ma
Hello all,
Over the last week I pushed several patches to enable prepend optimization in
some core containers, namely, QList, QString, QByteArray.
In the light of these changes, there may occur new subtle issues in your code.
New model
---
In a nutshell, prepend optimization code does some mag
32 matches
Mail list logo
