саров
Gesendet: Donnerstag, 18. März 2021 16:04
An: Qt development mailing list
Betreff: [Development] QHash references stability in Qt6
Hello, when porting Qbs to Qt6 I’ve noticed a lot of bugs/crashes when using
QHash. With Qt5 that was never a problem and simple change QHash ->
std::unord
Hello, when porting Qbs to Qt6 I’ve noticed a lot of bugs/crashes when using
QHash. With Qt5 that was never a problem and simple change QHash ->
std::unordered_map fixes those.
From what I understood all affected places rely on the fact that QHash in Qt5
(as well as std::unordered_map) guarante
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.
Hello guys,
There is a number of C++-style headers which AFAIU just include the
C-style header. I wonder why they do not appear in my workspace. Is
there some magic invocation of the build script which creates them
automatically?
--
Carry a towel
http://dataved.ru/
+7 916 562 8095
[1] Join Alexe
Hi,
As already pointed out by the other responders, this cannot be an error.
However, perhaps it could be a Clazy check? Because I doubt QHash does what the writer intented in the general case.
André
Op 18/01/2018 om 15:12 schreef René J.V. Bertin:
> Hi,
>
> It took me a while to figure out why
On Thursday, 18 January 2018 06:12:42 PST René J.V. Bertin wrote:
> It took me a while to figure out why my QHash map of a const char* to
> something else didn't work despite containing the expected key,value
> combinations. I understand that the bug was in my code rather than in
> QHash, because t
> On 18 Jan 2018, at 15:12, René J.V. Bertin wrote:
>
> Hi,
>
> It took me a while to figure out why my QHash map of a const char* to
> something else didn't work despite containing the expected key,value
> combinations. I understand that the bug was in my code rather than in QHash,
> becau
18.01.2018, 17:13, "René J.V. Bertin" :
> Hi,
>
> It took me a while to figure out why my QHash map of a const char* to
> something else didn't work despite containing the expected key,value
> combinations. I understand that the bug was in my code rather than in QHash,
> because the class is n
Hi,
It took me a while to figure out why my QHash map of a const char* to something
else didn't work despite containing the expected key,value combinations. I
understand that the bug was in my code rather than in QHash, because the class
is not designed to work with basic data types.
It could
Here is a solution using range-v3
https://github.com/cor3ntin/qt-iterate-over-associative-containers/blob/master/main.cpp
- there is of course room for improvement :)
2017-04-20 19:28 GMT+02:00 Matthew Woehlke :
> On 2017-04-20 13:18, Sergio Martins wrote:
> > On 2017-04-20 18:06, Matthew Woehlke
On 2017-04-20 13:18, Sergio Martins wrote:
> On 2017-04-20 18:06, Matthew Woehlke wrote:
>> for (auto i : qtEnumerate(my_hash))
>> do_stuff(i.key(), i.value());
>
> That doesn't work with temporaries, does it ?
No. Neither does std::add_const / qAsConst.
> Maybe something to fix in the C++
On 2017-04-20 18:06, Matthew Woehlke wrote:
On 2017-04-16 10:44, Corentin wrote:
If you want the same behavior, you can create a proxy for your
associative
container instance, with a custom iterator whose operator*() returns a
std
pair ( or a QPair ) - quite a bit of boilterplate code.
...or
On 2017-04-16 10:44, Corentin wrote:
> If you want the same behavior, you can create a proxy for your associative
> container instance, with a custom iterator whose operator*() returns a std
> pair ( or a QPair ) - quite a bit of boilterplate code.
...or use
https://github.com/Kitware/qtextensions
On Tuesday 18 April 2017 10:52:47 Olivier Goffart wrote:
> On Montag, 17. April 2017 18:48:26 CEST Marc Mutz wrote:
> > On Monday 17 April 2017 18:08:20 Thiago Macieira wrote:
> > > Em segunda-feira, 17 de abril de 2017, às 00:30:23 PDT, Marc Mutz
>
> escreveu:
> > > > The problem with QT_STRICT_I
On Montag, 17. April 2017 18:48:26 CEST Marc Mutz wrote:
> On Monday 17 April 2017 18:08:20 Thiago Macieira wrote:
> > Em segunda-feira, 17 de abril de 2017, às 00:30:23 PDT, Marc Mutz
escreveu:
> > > The problem with QT_STRICT_ITERATORS is _not_ that they are changing
> > > begin() and end(),
> >
Em segunda-feira, 17 de abril de 2017, às 09:48:26 PDT, Marc Mutz escreveu:
> On Monday 17 April 2017 18:08:20 Thiago Macieira wrote:
> > Em segunda-feira, 17 de abril de 2017, às 00:30:23 PDT, Marc Mutz
escreveu:
> > > The problem with QT_STRICT_ITERATORS is _not_ that they are changing
> > > beg
On Monday 17 April 2017 18:08:20 Thiago Macieira wrote:
> Em segunda-feira, 17 de abril de 2017, às 00:30:23 PDT, Marc Mutz escreveu:
> > The problem with QT_STRICT_ITERATORS is _not_ that they are changing
> > begin() and end(),
>
> Actually, it was. You can't use QT_STRICT_ITERATORS in one TU an
Em segunda-feira, 17 de abril de 2017, às 00:30:23 PDT, Marc Mutz escreveu:
> The problem with QT_STRICT_ITERATORS is _not_ that they are changing begin()
> and end(),
Actually, it was. You can't use QT_STRICT_ITERATORS in one TU and not in
other, regardless of exporting or not.
--
Thiago Maci
On Monday 17 April 2017 00:59:55 Thiago Macieira wrote:
> Em domingo, 16 de abril de 2017, às 15:16:54 PDT, Mark Gaiser escreveu:
> > Ohh, that's great!
> >
> >
> >
> > One question. Would it be possible and sane to - by default - provide
> > it as the patch implements it there, but with the addit
Em domingo, 16 de abril de 2017, às 15:16:54 PDT, Mark Gaiser escreveu:
> Ohh, that's great!
>
> One question. Would it be possible and sane to - by default - provide
> it as the patch implements it there, but with the addition of a define
> that can influence the behavior of the iterators?
Most
Em domingo, 16 de abril de 2017, às 15:09:16 PDT, Mark Gaiser escreveu:
> On Sun, Apr 16, 2017 at 5:53 PM, Thiago Macieira
>
> wrote:
> > Em domingo, 16 de abril de 2017, às 08:05:21 PDT, Mark Gaiser escreveu:
> >> That again makes me wonder, why did Qt diverge from that?
> >
> > We didn't diver
On Sun, Apr 16, 2017 at 9:48 PM, Samuel Gaist wrote:
>
>> On 16 Apr 2017, at 17:53, Thiago Macieira wrote:
>>
>> Em domingo, 16 de abril de 2017, às 08:05:21 PDT, Mark Gaiser escreveu:
>>> That again makes me wonder, why did Qt diverge from that?
>>
>> We didn't diverge. We never had that. The Qt
On Sun, Apr 16, 2017 at 5:53 PM, Thiago Macieira
wrote:
> Em domingo, 16 de abril de 2017, às 08:05:21 PDT, Mark Gaiser escreveu:
>> That again makes me wonder, why did Qt diverge from that?
>
> We didn't diverge. We never had that. The Qt style predates the Standard
> Library having relevance in
> On 16 Apr 2017, at 17:53, Thiago Macieira wrote:
>
> Em domingo, 16 de abril de 2017, às 08:05:21 PDT, Mark Gaiser escreveu:
>> That again makes me wonder, why did Qt diverge from that?
>
> We didn't diverge. We never had that. The Qt style predates the Standard
> Library having relevance in
Em domingo, 16 de abril de 2017, às 08:05:21 PDT, Mark Gaiser escreveu:
> That again makes me wonder, why did Qt diverge from that?
We didn't diverge. We never had that. The Qt style predates the Standard
Library having relevance in Qt. When the first QHash-like class was added, it
was just like
Qt wasn't initially designed with STL compatibility in mind ( in the early
2000, STL support was poor on most platforms and Qt actually predates c++98
- though QMap do not, I think). - I would argue that STL compatibility is
still an issue more often than not, but it's another discussion :)
As for
Very unlikely I'd say. Hashes are used all over the place in ppl' code and
making this change will break way too much to be sensible.
On Sun, Apr 16, 2017 at 6:05 PM, Mark Gaiser wrote:
> On Sun, Apr 16, 2017 at 4:44 PM, Corentin
> wrote:
> > Funny, a friend at kdab asked me about that exact qu
On Sun, Apr 16, 2017 at 4:44 PM, Corentin wrote:
> Funny, a friend at kdab asked me about that exact question a few minutes
> ago.
> The reason for the difference is most certainly an historical one ( and
> can't be changed because it would break quite a bit of code ).
>
> If you want the same beh
Funny, a friend at kdab asked me about that exact question a few minutes
ago.
The reason for the difference is most certainly an historical one ( and
can't be changed because it would break quite a bit of code ).
If you want the same behavior, you can create a proxy for your associative
container
Hi,
Take this simple example:
QHash test = {
{10, "aaa"},
{20, "bbb"},
{30, "ccc"}
};
for (const auto &entry: qAsConst(test)) {
qDebug() << entry;
}
It returns:
"aaa"
"ccc"
"bbb"
and the std::unordered_map version:
std::unordered_map test = {
{10, "aaa"},
{20,
On terça-feira, 17 de abril de 2012 12.02.00, Giuseppe D'Angelo wrote:
> On 17 April 2012 08:59, Olivier Goffart wrote:
> > By not salting the hash for integer.
> > Or only doing it before applying the %
>
> Or specialize some QHash / QHashNode member for int key and re-xoring
> with the seed?
Th
On 17 April 2012 08:59, Olivier Goffart wrote:
> By not salting the hash for integer.
> Or only doing it before applying the %
Or specialize some QHash / QHashNode member for int key and re-xoring
with the seed?
But I can't say I'm familiar with that code and will have no time to
do that asap --
On Tue, Apr 17, 2012 at 09:59:57AM +0200, ext Olivier Goffart wrote:
> On Sunday 15 April 2012 20:38:22 Thiago Macieira wrote:
> > On segunda-feira, 16 de abril de 2012 00.08.43, Olivier Goffart wrote:
> > > I'm just not really happy with the fact that you removed the optimisation
> > > for int to
On 4/17/12 9:59 AM, "ext Olivier Goffart" wrote:
>On Sunday 15 April 2012 20:38:22 Thiago Macieira wrote:
>> On segunda-feira, 16 de abril de 2012 00.08.43, Olivier Goffart wrote:
>> > On Saturday 14 April 2012 20:06:53 Giuseppe D'Angelo wrote:
>> > > So, after *too many* commits[1] -- QHash rand
On Sunday 15 April 2012 20:38:22 Thiago Macieira wrote:
> On segunda-feira, 16 de abril de 2012 00.08.43, Olivier Goffart wrote:
> > On Saturday 14 April 2012 20:06:53 Giuseppe D'Angelo wrote:
> > > So, after *too many* commits[1] -- QHash randomization was merged a
> > > few hours ago!
> > >
> >
On segunda-feira, 16 de abril de 2012 00.08.43, Olivier Goffart wrote:
> On Saturday 14 April 2012 20:06:53 Giuseppe D'Angelo wrote:
> > So, after *too many* commits[1] -- QHash randomization was merged a
> > few hours ago!
> >
> > https://qt.gitorious.org/qt/qtbase/commit/c01eaa438200edc9a3bbcd8ae
On Saturday 14 April 2012 20:06:53 Giuseppe D'Angelo wrote:
> So, after *too many* commits[1] -- QHash randomization was merged a
> few hours ago!
>
> https://qt.gitorious.org/qt/qtbase/commit/c01eaa438200edc9a3bbcd8ae1e8ded058
> bea268
>
> Thanks to all of the guys involved for the ideas, feedba
On Saturday, April 14, 2012 20:06:53 Giuseppe D'Angelo wrote:
> So, after *too many* commits[1] -- QHash randomization was merged a
> few hours ago!
>
> https://qt.gitorious.org/qt/qtbase/commit/c01eaa438200edc9a3bbcd8ae1e8ded058
> bea268
>
> Thanks to all of the guys involved for the ideas, feed
So, after *too many* commits[1] -- QHash randomization was merged a
few hours ago!
https://qt.gitorious.org/qt/qtbase/commit/c01eaa438200edc9a3bbcd8ae1e8ded058bea268
Thanks to all of the guys involved for the ideas, feedback, reviewing
the patches... and staging them :-)
Cheers,
--
Giuseppe D'A
Hi all,
thanks everybody for your feedback!
2012/3/19 Thiago Macieira :
> On segunda-feira, 19 de março de 2012 10.42.44, Thiago Macieira wrote:
>> [1] note that the order is stable. Two hashing tables with the same
>> elements must produce the same order.
>
> Actually, thinking a little more ab
On segunda-feira, 19 de março de 2012 10.42.44, Thiago Macieira wrote:
> [1] note that the order is stable. Two hashing tables with the same
> elements must produce the same order.
Actually, thinking a little more about this, I might be wrong.
If two elements produce the same hashing value (be i
On segunda-feira, 19 de março de 2012 11.17.29, André Somers wrote:
> Op 19-3-2012 10:42, Thiago Macieira schreef:
> > They shouldn't rely on that at all. The documentation of QHash says
> > that it produces an arbitrary but stable[1] order.
> >
> > [1] note that the order is stable. Two hashing ta
Op 19-3-2012 10:42, Thiago Macieira schreef:
> They shouldn't rely on that at all. The documentation of QHash says
> that it produces an arbitrary but stable[1] order.
> [1] note that the order is stable. Two hashing tables with the same
> elements must produce the same order.
If I understood
Am Montag, den 19.03.2012, 10:42 +0100 schrieb Thiago Macieira:
> On segunda-feira, 19 de março de 2012 10.04.28, Mathias Hasselmann wrote:
> > Am Montag, den 19.03.2012, 08:01 + schrieb Giuseppe D'Angelo:
> > > 2) Document to end users that it cannot be assumed that qHash output or
> > > QHash
On segunda-feira, 19 de março de 2012 10.04.28, Mathias Hasselmann wrote:
> Am Montag, den 19.03.2012, 08:01 + schrieb Giuseppe D'Angelo:
> > 2) Document to end users that it cannot be assumed that qHash output or
> > QHash iteration order are stable, so people must not rely on that.
>
> Would
Am Montag, den 19.03.2012, 08:01 + schrieb Giuseppe D'Angelo:
> 2) Document to end users that it cannot be assumed that qHash output or QHash
> iteration order are stable, so people must not rely on that.
Would that be sufficient to prevent 3rd-party code relying on stable
iteration order from
On Mon, Mar 19, 2012 at 9:01 AM, Giuseppe D'Angelo wrote:
> While I don't want to get involved in a flame about what's the
> Best String Hashing Algorithm Ever Devised By an Human Being™,
> I still think there's some room for making that change to go in.
to be clear, I abandoned this because:
1)
Hi,
sorry for the long message.
It's a pity to see that the proposed (and +2'd by Lars) improvement to
qHash(QString) [1] has been abandoned.
While I don't want to get involved in a flame about what's the
Best String Hashing Algorithm Ever Devised By an Human Being™,
I still think there's some ro
73 matches
Mail list logo
