+1!
Best regards,
Jesús
From: Development on behalf of Martin
Smith
Sent: 17 May 2019 07:05
To: Lorn Potter; development@qt-project.org
Subject: Re: [Development] Nominating Mikhail Svetkin for Approver status
+1 from martin
__
> No-one uses C++ unless they need the extra performance.
This is mostly right, though wide portability can be another reason.
This being said, that does not mean that every line of a C++ application
needs to be optimized with CPU cycles in mind.
In my experience, only restricted portions need to
On 2019-05-16 23:41, Konstantin Shegunov wrote:
you end up where the STL is - so convoluted it's hardly worth making
anything with it.
Qt is a C++ library. If you don't like C++, either stay in QML or use
Java. No-one uses C++ unless they need the extra performance.
It is not Qt's job to cha
+1 from martin
From: Development on behalf of Lorn Potter
Sent: Friday, May 17, 2019 1:45 AM
To: development@qt-project.org
Subject: Re: [Development] Nominating Mikhail Svetkin for Approver status
+1
On 17/5/19 12:45 AM, Volker Hilsheimer wrote:
> I’d
+1
On 17/5/19 12:45 AM, Volker Hilsheimer wrote:
I’d like to nominate Mikhail Svetkin for Approver status.
--
Lorn Potter
Freelance Qt Developer. Maintainer QtSensors, Qt WebAssembly
___
Development mailing list
Development@qt-project.org
https://li
On Fri, May 17, 2019 at 12:56 AM Konstantin Tokarev
wrote:
> In C++ there is a convention that ugly things should look ugly in code.
Have a reference for that convention?
> Removing element from the middle or beginning of contiguous container is
> ugly thing. If you need such operation in you
17.05.2019, 00:44, "Konstantin Shegunov" :
> User story:
> The API is always going to rule supreme over any implementation detail or
> efficiency. The API is what you present to the user, not the implementation.
> The moment you start sacrificing good API, one that's fleshed out and
> convenie
>
> On Thursday, 16 May 2019 08:26:08 PDT Mutz, Marc via Development wrote:
> This one is simple: Array of struct -> struct of arrays. Well-known
> optimisation in the games industry.
>
Assuming that the data structure is simple enough and can be kept
contiguous in memory, and the view can be simp
+1
Disclaimer: I sit on the other side of the wall from him.
From: Gatis Paeglis
Sent: Thursday, May 16, 8:09 PM
Subject: Re: [Development] Nominating Mikhail Svetkin for Approver status
To: Tor Arne Vestbø, Volker Hilsheimer
Cc: Qt development mailing list
+1, long-overdue 🙂
From: Development
On Thursday, 16 May 2019 11:00:58 PDT Иван Комиссаров wrote:
> > Another case would be where you're keeping extra data in the internal
> > structure and you need to filter that out before returning.
>
> And now trivial getter allocates and has an O(N) complexity.
>
> Please, don’t do changes like
Ah, ok, I missed that information, good to know.
> 16 мая 2019 г., в 22:43, Mikhail Svetkin
> написал(а):
>
>
> std::span introduced in c++20.
>
___
Development mailing list
Development@qt-project.org
https://lists.qt-project.org/listinfo/developme
Yes, you are right. range-v3 library is c++14 compatibly.
std::span introduced in c++20.
Best regards,
Mikhail
On Thu, 16 May 2019 at 22:29, Иван Комиссаров wrote:
> Correct me if I’m wrong, but gsl::span (or an array_view) conforms (one
> of) the ranges concept, i.e. it *is* a range.
>
> No
Correct me if I’m wrong, but gsl::span (or an array_view) conforms (one of) the
ranges concept, i.e. it *is* a range.
No need to wait for c++20 =)
> 16 мая 2019 г., в 22:23, Mikhail Svetkin
> написал(а):
>
> If we will return a range (C++20 accepted ranges) then we can provide better
> inte
+ 1 for idea with Views.
All Qt containers are implicit shared. Why do we need to pay all the time
for implicit shared when we don't need it?
Qt containers are hard to integrate with 3rd-party libraries which use std
containers.
Also when we return a container we are always depend on the API of
c
I doubt adding one if condition to QMap insert and remove methods would be
noticeable. I might be wrong. if i am and the user needs a QMap API with few
elements, then the user should write a QListMap of some sort, not a QList and
sprinkling the code with unnecessary for loops all over the place.
On Thu, May 16, 2019 at 06:31:13PM +, Paolo Angelelli wrote:
> i think you and alex stephanov are wrong. if QMap API is convenient,
> but does not perform for the few elements use case, optimize QMap for
> that use case,
And then everybody else pays with cycles for the detection of the
special
> If a user needs a regular container, range might be simply assigned to
it.
It depends on what you expect the average usecase to be.
If we assume that a regular container is generally more used then you are
preventing ppl from "almost always auto"
On Thu, May 16, 2019 at 9:35 PM Vitaly Fanaskov
Going forward, we should be looking into removing more and more owning
containers from the interface and replace them with views. The standard is
working on a solution for the stale reference problem, and by the time Qt 7
comes around, it will be hopefully widely available.
This is good directi
i think you and alex stephanov are wrong. if QMap API is convenient, but does
not perform for the few elements use case, optimize QMap for that use case, and
don't make people write thousands of unnecessary for loops. From: Mutz, Marc
via Development Sent: Thursday, May 16, 20:21 Subject: Re: [D
On 2019-05-16 18:29, Thiago Macieira wrote:
On Thursday, 16 May 2019 08:26:08 PDT Mutz, Marc via Development wrote:
[...]
I believe the opposite to be true: I believe owning container use in
the
API to break a class' encapsulation:
If you return QVector<>, which choices do you have for the in
+1, long-overdue 🙂
From: Development on behalf of Tor Arne
Vestbø
Sent: Thursday, May 16, 2019 6:14 PM
To: Volker Hilsheimer
Cc: Qt development mailing list
Subject: Re: [Development] Nominating Mikhail Svetkin for Approver status
+2
> On 16 May 2019, at 16:45,
> 16 мая 2019 г., в 18:29, Thiago Macieira
> написал(а):
>
> When you first design the class, sure. But 5 years later, you may have the
> data internally kept in a QMap or QHash, mapped to some other information. So
> your function that used to "return d->member;" now does
> "return d->memb
On Thursday, 16 May 2019 08:26:08 PDT Mutz, Marc via Development wrote:
> > That goes against the Qt API design. Do not return views, since it
> > implies
> > that internally there is an object that produces that view and that it
> > does
> > not go out of scope. The reason we return full, owning c
+2
> On 16 May 2019, at 16:45, Volker Hilsheimer wrote:
>
> Hi,
>
>
> I’d like to nominate Mikhail Svetkin for Approver status. He’s been an active
> contributor since March 2018, working on C++11’ifying Qt, contributing to
> core QPA, network code, the QtHttpServer labs project, and right n
On 2019-05-16 16:55, Thiago Macieira wrote:
On Thursday, 16 May 2019 06:05:37 PDT Mutz, Marc via Development wrote:
Going forward, we should be looking into removing more and more owning
containers from the interface and replace them with views. The
standard
is working on a solution for the st
On Thursday, 16 May 2019 06:05:37 PDT Mutz, Marc via Development wrote:
> Going forward, we should be looking into removing more and more owning
> containers from the interface and replace them with views. The standard
> is working on a solution for the stale reference problem, and by the
> time Qt
Hi,
I’d like to nominate Mikhail Svetkin for Approver status. He’s been an active
contributor since March 2018, working on C++11’ifying Qt, contributing to core
QPA, network code, the QtHttpServer labs project, and right now the integration
of changes for RTEMS into qtbase.
He’s also been ac
Hi Lars,
On 2018-11-02 08:51, Lars Knoll wrote:
I believe I have a solution to get rid of QList without breaking SC in
any major way. See https://codereview.qt-project.org/#/c/242199/ and
the following changes.
[...]
So to re-iterate: We will not break SC in major ways. The goal is to
make por
Another +1.
Disclaimer: I was his mentor and office-mate for his first year and a bit.
Eddy.
From: Development on behalf of Paul
Wicking
Sent: 15 May 2019 13:11
To: development@qt-project.org
Subject: [Development] Nominating Ryan Chu for Appro
29 matches
Mail list logo
