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
ing free functions:
template bool isEmptyQt(const T &t) { return t.empty(); }
martin
From: Development on behalf of Иван
Комиссаров
Sent: Tuesday, December 24, 2019 10:43 AM
To: Kevin Kofler
Cc: development@qt-project.org
Subject: Re: [Development] QHas
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
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.
So “someone else’s problem” affects customers - what’s the point of having fast
hash if it misses features customer needs?
Writing containers is fun,
On 20/12/19 13:47, Giuseppe D'Angelo via Development wrote:
> Just to be devil's advocate, there is... As much as it's fun and
> everything implementing a container, just using std::unordered_map would
> have minimal effort on our side ("someone else's problem", and it's not
> even a random 3rd par
Il 20/12/19 16:05, Vitaly Fanaskov ha scritto:
I'm not totally sure I understand this point. What do you mean by
"memory management"?
Inside of containers you need to allocate and de-allocate memory. If
container is passed across a library boundary, there is a question what
version of new/delete
On Friday, 20 December 2019 07:05:15 PST Vitaly Fanaskov wrote:
> If
> container is passed across a library boundary, there is a question what
> version of new/delete should be used.
There's only one global operator new and delete. Anything else is a nightmare,
fragile, prone to mistakes and only
On Fri, Dec 20, 2019 at 02:47:06PM +0100, Giuseppe D'Angelo via Development
wrote:
> Il 20/12/19 12:20, Philippe ha scritto:
> > std::unordered_map is before all an interface and the implemenation varies
> > according to the library supplier.
> > And this, potentially much more eg. than std::vect
> I'm not totally sure I understand this point. What do you mean by
> "memory management"?
Inside of containers you need to allocate and de-allocate memory. If
container is passed across a library boundary, there is a question what
version of new/delete should be used. But this can be "easily"
> On 20 Dec 2019, at 15:14, Giuseppe D'Angelo via Development
> wrote:
>
> Il 20/12/19 13:54, Vitaly Fanaskov ha scritto:
>> This is not that easy to use std::* containers because at least the
>> following issues have to be addressed:
>> * Memory management
>> * Binary compatibility
>> *
Il 20/12/19 13:54, Vitaly Fanaskov ha scritto:
This is not that easy to use std::* containers because at least the
following issues have to be addressed:
* Memory management
* Binary compatibility
* Implementation consistency
You probably can provide, for example, some allocators, relax
On Fri, 20 Dec 2019 at 15:48, Giuseppe D'Angelo via Development
wrote:
>
> Il 20/12/19 12:20, Philippe ha scritto:
> > std::unordered_map is before all an interface and the implemenation varies
> > according to the library supplier.
> > And this, potentially much more eg. than std::vector.
> > An
On Fri, 20 Dec 2019 at 13:24, Philippe wrote:
>
> >> just using std::unordered_map would have minimal effort on our side
> >> ("someone else's problem", and it's not even a random 3rd party...)
>
> std::unordered_map is before all an interface and the implemenation varies
> according to the libra
Il 20/12/19 14:57, Ulf Hermann ha scritto:
The fun starts when the user works with Nice3rdPartyHash in their
application, then transforms it into QHash to use our public API, which
we then transform into QReallyGreatHash for internal usage.
Sure, but how often do we transfer containers ownershi
> And my point was that Qt shouldn't _really_ bother reinventing something
> already easily available elsewhere. Usage of a "fast hash" internally to
> Qt doesn't mean we provide that API to our user (hello, QFlatMap; or
> std::vector usages all over Qt internals.).
The fun starts when the user
Il 20/12/19 12:20, Philippe ha scritto:
std::unordered_map is before all an interface and the implemenation varies
according to the library supplier.
And this, potentially much more eg. than std::vector.
And X-Platorm Qt users would expect performance consistency I guess.
Devil's advocate, aga
This is not that easy to use std::* containers because at least the following
issues have to be addressed:
* Memory management
* Binary compatibility
* Implementation consistency
You probably can provide, for example, some allocators, relax compatibility
requirements and so on... T
>> just using std::unordered_map would have minimal effort on our side
>> ("someone else's problem", and it's not even a random 3rd party...)
std::unordered_map is before all an interface and the implemenation varies
according to the library supplier.
And this, potentially much more eg. than std:
+10
It's excellent because it behaves very well in multiple scenarios, which
is uncommon for a hash map.
And according to your design, it should perform equally well with very small
maps.
And all that under 1000 lines of code, this is brillant (BTW, you need to
#include in qthash.h)
Given the
On 20 Dec 2019, at 11:47, Giuseppe D'Angelo via Development
mailto:development@qt-project.org>> wrote:
Il 20/12/19 09:23, Lars Knoll ha scritto:
The result was that QHash has clear weaknesses compared to other
implementations. It uses too much memory and certainly isn’t the fastest
implementat
Il 20/12/19 09:23, Lars Knoll ha scritto:
The result was that QHash has clear weaknesses compared to other
implementations. It uses too much memory and certainly isn’t the fastest
implementation. But std::unordered_map is just as bad, so there’s no point in
using that to implement QHash.
Jus
On Fri, 20 Dec 2019 at 10:25, Lars Knoll wrote:
>
> Hi,
>
> I’ve been playing around with QHash during our recent Hackathon at The Qt
> Company. I started with measuring and comparing our implementation with
> various others that are out there using the benchmark that’s described here:
> https:
Hi,
I’ve been playing around with QHash during our recent Hackathon at The Qt
Company. I started with measuring and comparing our implementation with various
others that are out there using the benchmark that’s described here:
https://tessil.github.io/2016/08/29/benchmark-hopscotch-map.html.
26 matches
Mail list logo
