Il 24/12/19 10:12, Kevin Kofler ha scritto:
It's funny because I have that issue each time I am forced to work with
somebody else's STL containers. :-) (Sometimes, can help, e.g.,
to find an element in an std::vector, but its arcane syntax with the pair of
iterators is a pain compared to just ca
On 24-12-19 11:28, Martin Smith wrote:
However, instead of adding
template bool qIsEmpty(const T &t) { return t.empty(); }
we keep discussing how ugly std is=)
But that's kind of ugly too. I read it as qlsEmpty(), not qIsEmpty(). See what
I mean? On of those is a lower case L.
How about a new
>However, instead of adding
>template bool qIsEmpty(const T &t) { return t.empty(); }
>we keep discussing how ugly std is=)
But that's kind of ugly too. I read it as qlsEmpty(), not qIsEmpty(). See what
I mean? On of those is a lower case L.
How about a new approach to adding free functions:
te
Il 23/12/19 09:10, Alberto Mardegan ha scritto:
I'm not sure the "someone else's problem" argument would go down very
well with Qt customers. :-)
Why not? Why would any user care about _who_
implements QHash internals?
Using std::* classes in the Qt implementation is not a bad idea, but
o
That’s why in Qbs we have «stlutils» header [0]
I think, I already proposed in one of the similar Qt vs std threads an addition
of free functions to make life easier with std:: containers. As far as I
remember, Thiago’s main argument against using std::vector was that .empty()
looks ugly (and I
Иван Комиссаров wrote:
> Well, every time I use (or try to use) QStringView I encounter the problem
> of missing methods/functionality. The same applies to the Qt containers.
It's funny because I have that issue each time I am forced to work with
somebody else's STL containers. :-) (Sometimes, c
