[Development] implicit sharing and iterators in qt containers

Mandeep Sandhu mandeepsandhu.chd at gmail.com
Tue Aug 1 00:35:15 CEST 2017


On Mon, Jul 31, 2017 at 2:57 PM, Thiago Macieira <thiago.macieira at intel.com>
wrote:

> On segunda-feira, 31 de julho de 2017 14:36:59 PDT Mandeep Sandhu wrote:
> > > I'd expect to be able to use keys that do not define qHash or qLess.
> >
> > Why?
>
> My type key type may be or contain an opaque non-orderable type, which
> would
> make implementing both qHash and qLess impossible. Right now, if you have
> such
> a key type, you can't use QMap or QHash. Example type: QVariant.
>
> Therefore, for this new container to add something we currently do not
> have,
> it MUST NOT require either function.
>

Okay, I got your point now. Although wouldn't the user be expecting this,
given that other containers (STL containers, python dicts) also impose the
same constraints? Isn't it a fair trade-off for faster lookup?


> > > Search would be O(n). So be it.
> >
> > Well it wouldn't be much of a "map" then, would it?
>
> Sure it would. There's nothing that requires associative containers to have
> search times better than O(n). It just happens that both std::map and QMap
> implements them at O(log n).


Well, if fast lookup isn't necessary, then I guess such a "container" is
not really needed, and one can simply implement it using a
QLinkedList<QPair<Key key, Value value>> (maybe with some added
restrictions).

-mandeep


>

> --
> Thiago Macieira - thiago.macieira (AT) intel.com
>   Software Architect - Intel Open Source Technology Center
>
> _______________________________________________
> 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/20170731/3ef87ade/attachment.html>


More information about the Development mailing list