[Development] QHash iteration vs std::unordered_map
markg85 at gmail.com
Mon Apr 17 00:16:54 CEST 2017
On Sun, Apr 16, 2017 at 9:48 PM, Samuel Gaist <samuel.gaist at edeltech.ch> wrote:
>> On 16 Apr 2017, at 17:53, Thiago Macieira <thiago.macieira at intel.com> 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 Qt. When the first QHash-like class was added, it
>> was just like that.
>> Also remember that at the time, you wouldn't think of a Standard Library
>> associative container as such. It was just a sequential container that held a
>> std::pair, with some convenience functions for searching the first of the pair.
>> Returning a pair was a consequence of that. I don't know if it was intentional
>> thinking, or it just happened.
>>> And... if Qt plans to change it in Qt6?
>> No, cannot due to source compatibility. Ever.
>> Thiago Macieira - thiago.macieira (AT) intel.com
>> Software Architect - Intel Open Source Technology Center
>> Development mailing list
>> Development at qt-project.org
> Just in case, there’s a work in progress at
> to add these "missing" iterators to QHash and QMap.
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?
For instance a "QT_STL_COMPATIBLE_ITERATORS" (just made that up,
doesn't exist) when defined gives the iterators
begin/constBegin/cbegin/enc/constEnd/cend STL compatible output (so
give an std::pair with key and value)?
When not defined (the default i guess) it falls back to what Qt uses now.
Providing this option makes the Qt containers easier to use with STL algorithms.
More information about the Development