[Development] QHash iteration vs std::unordered_map

[Corentin]

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 instance, with a custom iterator whose operator*() returns a std
pair ( or a QPair ) - quite a bit of boilterplate code.




Le dim. 16 avr. 2017 à 15:57, Mark Gaiser <markg85 at gmail.com> a écrit :

> Hi,
>
> Take this simple example:
>
>   QHash<int, QString> 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<int, QString> test = {
>     {10, "aaa"},
>     {20, "bbb"},
>     {30, "ccc"}
>   };
>
>   for (const auto &entry: test) {
>     qDebug() << entry;
>   }
>
> it returns:
> std::pair(30,"ccc")
> std::pair(10,"aaa")
> std::pair(20,"bbb")
>
> As you can see, the QHash iteration directly returns the value. The
> std::unordered_map returns a std::par with the key and value for the
> current iteration (in it's respective first and second members). Both
> approaches probably have arguments in favor and against. What i'm
> curious about is why there is a difference at all?
>
> I'm curious because the behavior is a bit unexpected when compared to
> std::unordered_map. I would have guessed QHash to follow the same
> logic as std::unordered_map, only with a Qt syntax. So for instance a
> return of QPair(...), not the value directly.
>
> Thanks,
> Mark
> _______________________________________________
> Development mailing list
> Development at qt-project.org
> http://lists.qt-project.org/mailman/listinfo/development
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.qt-project.org/pipermail/development/attachments/20170416/3da4d3f2/attachment.html>