On Fri, 20 Dec 2019 at 15:48, Giuseppe D'Angelo via Development <[email protected]> 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. > > And X-Platorm Qt users would expect performance consistency I guess. > > Devil's advocate, again: this also applies, say, to std algorithms. Or > operator new. Should we stop using them and roll our own?
Do you expect to be able to write a significantly better std::for_each? find_if? sort? For operator new.. well, we already replace it with a better one in some cases. If we could eat the cost, we might seriously consider allocators, too. > > And that's the whole point of Lars' proposal. > 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.). Well, in this case, we are providing the same API as before, but with a better implementation. _______________________________________________ Development mailing list [email protected] https://lists.qt-project.org/listinfo/development
