Bubke Marco wrote:
> Actually this convince is hurting you if you need performance. I would
> prefer the convenience on top of lower level api.
[and at the end:]
> It really depends what you want to do. I would prefer it we had a CoW
> wrapper around std vector. Best of both worlds.
The question i
On January 16, 2016 00:44:57 Kevin Kofler wrote:
> Marc Mutz wrote:
>
>> On Friday 15 January 2016 03:58:12 Kevin Kofler wrote:
>>> So why not just add a QOptional that works the same as std::optional?
>>
>> a) because we can't (we don't yet require the necessary language features)
>
> A QOptio
Marc Mutz wrote:
> And you will see it over and over again until enough people are fixing
> premature pessimisations in existing Qt code. There's a notable increase
> already. But it takes a long time to turn a supertanker around...
Well, if …
> This is the old difference: you think using std::ve
Marc Mutz wrote:
> On Friday 15 January 2016 03:58:12 Kevin Kofler wrote:
>> So why not just add a QOptional that works the same as std::optional?
>
> a) because we can't (we don't yet require the necessary language features)
A QOptional that works with Qt's implicitly-shared data objects (such
Hi Lisandro,
Lisandro Damián Nicanor Pérez Meyer wrote:
> Hi! With my Debian packager hat on, we are receiving bugs like [bug] in
> which applications using QML with video cards that do not support OpenGL
> 2.0 (yes, there are people using 15+ years old video cards out there)
> makes stuff crash.
On Friday 15 January 2016 18:42:43 Marc Mutz wrote:
> And you will see it over and over again until enough people are fixing
> premature pessimisations in existing Qt code. There's a notable increase
> already. But it takes a long time to turn a supertanker around...
Some of us call them "trade-
On Friday 15 January 2016 08:08:52 charleyb123 . wrote:
> In our codebase, we've "wrapped" the std:: containers for stable-and-safe
> interfaces. Huge dividends. You can get (unsafe) direct access to the
> embedded std:: entity if you want. This is another option/mechanism for
> how we might evo
On Fri, 15 Jan 2016, Marc Mutz wrote:
And no, I cannot believe that using the Qt containers leads to faster
applications. It may lead to applications faster, but not to faster
applications.
Amen! Now each side of the discussion please pick one of the above
possible outcomes and be happy :)
Hi Bo,
On Friday 15 January 2016 12:40:05 Bo Thorsen wrote:
> We have seen this rant from you several times before.
And you will see it over and over again until enough people are fixing
premature pessimisations in existing Qt code. There's a notable increase
already. But it takes a long time t
On Friday 15 January 2016 11:28:32 Иван Комиссаров wrote:
> I've already heard those arguments, however we _can't_ use std::vector in
> API, because it's implementation may differ between compliers (gcc and
> clang stdlibs, for example).
> But we can use some features that implemented in the same w
On 2016-01-15 06:40, Bo Thorsen wrote:
> I would not mind removing some (maybe even most) of the Qt containers
> for Qt 6 or 7 and forcing people to learn the use std instead. Hash,
> map, set and linked list would be the first I'd get rid of.
Ugh... I *really* hate the idiotic insistence of std c
Apologies for "hijacking" the thread, but two points were raised that IMHO
would be helpful if they were answered directly:
(1) Future of Qt binary compatibility
(2) Use of std:: containers (especially in context of (1)).
We can take this to another thread as-needed. However, quick "recap":
===
Hi! With my Debian packager hat on, we are receiving bugs like [bug] in which
applications using QML with video cards that do not support OpenGL 2.0 (yes,
there are people using 15+ years old video cards out there) makes stuff crash.
It is totally fine that QML requires at least OpenGL 2.0, but
Den 15-01-2016 kl. 12:20 skrev Marc Mutz:
Consider QVector: it has been Qt-ifed by both adding (technically) useless
duplicate Qt-ish API, CoW, and a Qt-specific type classification scheme plus
corresponding optimisations that make it very hard to argue for std::vector
use instead. The Qt communi
On Fri, Jan 15, 2016 at 11:28 AM, Иван Комиссаров wrote:
> I've already heard those arguments, however we _can't_ use std::vector in
> API, because it's implementation may differ between compliers (gcc and
> clang stdlibs, for example).
We might reopen the case about why we should care at prese
I've already heard those arguments, however we _can't_ use std::vector in
API, because it's implementation may differ between compliers (gcc and
clang stdlibs, for example).
But we can use some features that implemented in the same way (std::pair or
std::exception).
You can continue to say how bad
On Friday 15 January 2016 03:58:12 Kevin Kofler wrote:
> Иван Комиссаров wrote:
> > Still, what about policy not to use std:: classes in Qt API?
>
> So why not just add a QOptional that works the same as std::optional?
a) because we can't (we don't yet require the necessary language features)
b)
17 matches
Mail list logo
