> I start wondering if it is possible to wrap the STL containers in Qt6 and
> give them a
> nice, intuitive, Qt-like API while still providing full STL compatibility. I
> am sure this
> has been evaluated. Are the results documented somewhere?
A few years ago my application was affected by a bug
>Please watch one of Lakos' recent allocator's talks for a ton of benchmarks
>how a custom
> allocator helps speed up - not just std::vector but also std::map, if
> one is so inclined.
I fully agree with this topic (and kudos for Lakos in general).
That's actually a lack in Qt containers: no al
Il 17/05/19 09:35, Bernhard Lindner ha scritto:
I start wondering if it is possible to wrap the STL containers in Qt6 and give
them a
nice, intuitive, Qt-like API while still providing full STL compatibility. I am
sure this
has been evaluated. Are the results documented somewhere?
I've done t
On 2019-05-17 08:12, Philippe wrote:
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 expe
On Fri, May 17, 2019 at 8:49 AM Mutz, Marc via Development <
development@qt-project.org> wrote:
> 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.
>
I may or may not like where C++ is going, but that's really bes
> you end up where the STL is - so convoluted it's hardly worth making
> anything with it.
I agree. The horrid of STL was one of the reasons for me to use Qt. Everything
is
complicated to the maximum in STL. Qt is so much more intuitive, it is fast to
learn and
fun to use (except when hitting a
> 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
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
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
ing the code with unnecessary for loops all over the
> place. From: André Pönitz Sent: Thursday, May 16, 20:46 Subject: Re:
> [Development] Views To: Paolo Angelelli Cc: development@qt-project.org On
> Thu, May 16, 2019 at 06:31:13PM +, Paolo Angelelli wrote: > i think you
> and alex
. From: André
Pönitz Sent: Thursday, May 16, 20:46 Subject: Re: [Development] Views To: Paolo
Angelelli Cc: development@qt-project.org 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 p
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
t: Re: [Development] Views
To: development@qt-project.org [1] Paraphrasing what Alex Stepanov teaches in
his A9 courses: No C programmer would _ever_ get the idea to use a
self-rebalancing red-black tree for something that holds a dozen elements.
Because once you understand what is required to impl
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
> 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
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
101 - 123 of 123 matches
Mail list logo
