On Mon, Jul 31, 2017 at 2:57 PM, Thiago Macieira <thiago.macie...@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@qt-project.org > http://lists.qt-project.org/mailman/listinfo/development >
_______________________________________________ Development mailing list Development@qt-project.org http://lists.qt-project.org/mailman/listinfo/development