On Thu, May 23, 2019 at 8:12 AM Mutz, Marc via Development <
development@qt-project.org> wrote:
> On 2019-05-22 22:38, Konstantin Shegunov wrote:
> > What about a rather smart (in terms of storage) circular buffer; a
> > vector. Then the push, pop, enqueue and dequeue would be amortized
> > O(1)?
On 2019-05-22 22:38, Konstantin Shegunov wrote:
What about a rather smart (in terms of storage) circular buffer; a
vector. Then the push, pop, enqueue and dequeue would be amortized
O(1)?
You mean like QCircularBuffer?
___
Development mailing list
Dev
On Wednesday, 22 May 2019 13:38:31 PDT Konstantin Shegunov wrote:
> What about a rather smart (in terms of storage) circular buffer; a vector.
> Then the push, pop, enqueue and dequeue would be amortized O(1)?
That's why std::queue is an adaptor, not a container. You can choose the
container it w
On Wed, May 22, 2019 at 11:30 PM Thiago Macieira
wrote:
> More important than the prepend (unshift) optimisation, QQueue benefits
> from
> the takeFirst (shift) optimisation. That can be added to QVector by making
> by
> moving the begin pointer.
>
What about a rather smart (in terms of storage)
On Wednesday, 22 May 2019 12:15:55 PDT Mutz, Marc via Development wrote:
> On 2019-05-22 18:25, Иван Комиссаров wrote:
> > What about fast prepend in [QList]
>
> Please look at the source and do experiments. Years ago, I think I found
> that it's just not true. There's a prepend optimisation, yes,
Hi Lars,
On 2019-05-22 15:49, Lars Knoll wrote:
Let’s conclude the topic of QList. I do see the concern about silent
source breakages. Here’s what we’ll (I’ll) do then for Qt 6:
1. Rename QList to QArrayList and make QList an alias to QArrayList
Agreed.
2. Move QStringList and QByteArrayLis
On Mittwoch, 22. Mai 2019 20:18:55 CEST Giuseppe D'Angelo via Development
wrote:
> Il 22/05/19 20:14, Konstantin Tokarev ha scritto:
> >>> FWIW, std::deque is implemented as a peculiar data strucutre which is
> >>> not really contiguous, and it may perform worse than QList in certain
> >>> cas
> This was a case where I thought it is obvious already. The definition of
> "Done" (given by Thiago earlier in this thread) has not applied for a
> long time anymore. There hasn't been maintainer for a long time. I
> understand this leave use cases in the dust but this can only by averted
> if so
On 2019-05-22 18:25, Иван Комиссаров wrote:
What about fast prepend in [QList]
Please look at the source and do experiments. Years ago, I think I found
that it's just not true. There's a prepend optimisation, yes, but it
only kicks in if you _only_ do prepends. If you mix in but a single
app
On Wednesday, 22 May 2019 09:25:18 PDT Иван Комиссаров wrote:
> > 4. Use QVector to implement QList, if sizeof(Foo) <= sizeof(quint64)
> > and Foo is movable
> What about fast prepend in that case? People tend to use QList as a deque
> because of the fast prepend/take first
It's possible to implem
On Wed, May 22, 2019 at 09:02:13PM +0300, Konstantin Tokarev wrote:
>
>
> 22.05.2019, 20:55, "André Pönitz" :
> > On Wed, May 22, 2019 at 07:41:42PM +0300, Konstantin Tokarev wrote:
> >> 22.05.2019, 19:38, "Philippe" :
> >> >> People tend to use QList as a deque because of the fast prepend/tak
22.05.2019, 21:19, "Giuseppe D'Angelo" :
> Il 22/05/19 20:14, Konstantin Tokarev ha scritto:
FWIW, std::deque is implemented as a peculiar data strucutre which is
not really contiguous, and it may perform worse than QList in certain cases
>>> [citation needed], as usual.
>> https:
Il 22/05/19 20:14, Konstantin Tokarev ha scritto:
FWIW, std::deque is implemented as a peculiar data strucutre which is not
really contiguous, and it may perform worse than QList in certain cases
[citation needed], as usual.
https://en.cppreference.com/w/cpp/container/deque
"As opposed to s
22.05.2019, 21:10, "Giuseppe D'Angelo via Development"
:
> Il 22/05/19 18:32, Konstantin Tokarev ha scritto:
>>> What about fast prepend in that case? People tend to use QList as a deque
>>> because of the fast prepend/take first
>> FWIW, std::deque is implemented as a peculiar data strucutre
Hi,
Il 22/05/19 15:49, Lars Knoll ha scritto:
1. Rename QList to QArrayList and make QList an alias to QArrayList
2. Move QStringList and QByteArrayList over to inherit from QVector (that
should be source compatible)
3. Rename QStringList to QStringVector (keep QStringList as a compatibility
n
Il 22/05/19 18:32, Konstantin Tokarev ha scritto:
What about fast prepend in that case? People tend to use QList as a deque
because of the fast prepend/take first
FWIW, std::deque is implemented as a peculiar data strucutre which is not
really contiguous, and it may perform worse than QList in
True. I am just trying to provide alternative view. I am perhaps
overexaggerating a bit, but I still think this is something that needs to
be considered.
And yeah, QList=QArrayList should definitely be a default setting
On Wed, May 22, 2019 at 9:00 PM Giuseppe D'Angelo
wrote:
> Il 22/05/19 19:29
22.05.2019, 20:55, "André Pönitz" :
> On Wed, May 22, 2019 at 07:41:42PM +0300, Konstantin Tokarev wrote:
>> 22.05.2019, 19:38, "Philippe" :
>> >> People tend to use QList as a deque because of the fast prepend/take
>> first
>> >
>> > Simply, QArrayList should not be deprecated.
>> > It is
Il 22/05/19 19:29, NIkolai Marchenko ha scritto:
I do not see how this addresses the issue. You are pushing the decision
to use the compile switch or not on the same userbase who couldn't be
bothered to port away from qlist in the first place.
You are essenitally asking: "Are you sure you aren't
On Wed, May 22, 2019 at 07:41:42PM +0300, Konstantin Tokarev wrote:
>
>
> 22.05.2019, 19:38, "Philippe" :
> >> People tend to use QList as a deque because of the fast prepend/take first
> >
> > Simply, QArrayList should not be deprecated.
> > It is also useful to store large objects that needs t
Ugh, apparently I answered to Lars directly instead of the whole ML >_< See
below
I do not see how this addresses the issue. You are pushing the decision to
use the compile switch or not on the same userbase who couldn't be bothered
to port away from qlist in the first place.
You are essenitally a
22.05.2019, 19:38, "Philippe" :
>> People tend to use QList as a deque because of the fast prepend/take first
>
> Simply, QArrayList should not be deprecated.
> It is also useful to store large objects that needs to be sorted.
In the latter QList can be replaced with std::vector> or
QVector>
> People tend to use QList as a deque because of the fast prepend/take first
Simply, QArrayList should not be deprecated.
It is also useful to store large objects that needs to be sorted.
Philippe
On Wed, 22 May 2019 18:25:18 +0200
?? wrote:
> 4. Use QVector to implement QList, if
22.05.2019, 19:28, "Иван Комиссаров" :
>> 4. Use QVector to implement QList, if sizeof(Foo) <= sizeof(quint64)
>> and Foo is movable
>
> What about fast prepend in that case? People tend to use QList as a deque
> because of the fast prepend/take first
FWIW, std::deque is implemented as a pecul
> 4. Use QVector to implement QList, if sizeof(Foo) <= sizeof(quint64) and
> Foo is movable
What about fast prepend in that case? People tend to use QList as a deque
because of the fast prepend/take first
Иван Комиссаров
> 22 мая 2019 г., в 15:49, Lars Knoll написал(а):
>
> Let’s conclude th
Il 22/05/19 09:11, Alex Blasche ha scritto:
This was a case where I thought it is obvious already. The definition of "Done"
(given by Thiago earlier in this thread) has not applied for a long time anymore. There
hasn't been maintainer for a long time. I understand this leave use cases in the du
Let’s conclude the topic of QList. I do see the concern about silent source
breakages. Here’s what we’ll (I’ll) do then for Qt 6:
1. Rename QList to QArrayList and make QList an alias to QArrayList
2. Move QStringList and QByteArrayList over to inherit from QVector (that
should be source compati
On 2019-05-22 09:09, Alex Blasche wrote:
From: Volker Hilsheimer
A version-controlled configuration file with user names and privileges
would provide that,
with the added benefit of making the list of approvers easily visible
to everyone with
read-acces
Volker Hilsheimer had said:
>>> A version-controlled configuration file with user names and privileges
>>> would provide that,
>>> with the added benefit of making the list of approvers easily visible to
>>> everyone with
>>> read-access to the respective repo. Right now, only Gerrit-admins have
Hi!
We have now soft branched '5.12.4' from '5.12'. So all new changes targeted to
Qt 5.12.4 release should be done in '5.12.4' instead. Final downmerge from
'5.12' to '5.12.4' will happen Monday 27th May so there is enough time to
finalize ongoing changes in '5.12' and start using '5.12.4'.
Ta
Hi all,
the Qt Project Security Policy is currently documented as a wiki page at [1].
Since QUIPs are the official way to document processes, I’m proposing that we
are moving the policy to a QUIP.
As a starting point, this will be a rst-ified version of the current wiki page:
https://coderevie
> -Original Message-
> From: Development On Behalf Of
> Florian Bruhin
> Sent: Monday, May 20, 2019 10:50 AM
> To: development@qt-project.org
> Subject: [Development] Proposal: Using Gerrit for new approver proposals?
>[...]
> What about using Gerrit to do so? I'm not sure how the reposito
Kai Köhne (21 May 2019 12:24) wrote:
> Anyhow, I'm not sure the QtWebView API is actually capable enough to
> cater for Qt Assistant. One obvious challenge is that you've to pass a
> url to the engine that it can actually resolve. This probably means
> either extracting the html in the .qch files t
> On 22 May 2019, at 10:09, Alex Blasche wrote:
>
> From: Volker Hilsheimer
>
>> A version-controlled configuration file with user names and privileges would
>> provide that,
>> with the added benefit of making the list of approvers easily visible to
>>
From: Volker Hilsheimer
>A version-controlled configuration file with user names and privileges would
>provide that,
>with the added benefit of making the list of approvers easily visible to
>everyone with
>read-access to the respective repo. Right now,
> On 22 May 2019, at 09:20, Alex Blasche wrote:
>
>> -Original Message-
>> From: Development On Behalf Of
>> Thiago Macieira
>> Sent: Monday, 20 May 2019 17:20
>> To: development@qt-project.org
>> Subject: Re: [Development] Proposal: Using Gerrit for new approver proposals?
>>
>> On Mon
> -Original Message-
> From: Development On Behalf Of
> Thiago Macieira
> Sent: Monday, 20 May 2019 17:20
> To: development@qt-project.org
> Subject: Re: [Development] Proposal: Using Gerrit for new approver proposals?
>
> On Monday, 20 May 2019 01:50:03 PDT Florian Bruhin wrote:
> > Wh
Hi Thiago,
We will not merge the contributor summit with the world summit. We received too
much feedback that such colocation in time is not desirable. Lots of people are
busy preparing for the world summit or have trainings and therefore could not
really participate on the contributor summit.
> -Original Message-
> From: Development On Behalf Of
> Giuseppe D'Angelo via Development
> I think both XML and XMLPatterns are Done, not Deprecated.
>
> Reasoning: only the former has an explicit note in the documentation (can't
> find
> an equivalent for the latter):
>
> > https:
39 matches
Mail list logo
