marc at kdab.com
Wed Jun 12 10:28:19 CEST 2019
On 2019-06-12 09:20, Ulf Hermann wrote:
>> I don't think that (non-)COW is a problem in the scenario under
> Having the thing COW makes the porting simpler at the cost of
> performance. If we wrote a COW container as a drop-in replacement for
> QMap or QHash with equivalent behavior we could just s/QMap/QFlatMap/g
> in Qt code and the issue would largely be solved.
As I said earlier: there's no alternative to thinking. There's no one
container that fits all use-cases. QFlatMap isn't it, either. It has
linear insertion behaviour, and it invalidates iterators on remove. You
need to analyse each use of QMap before replacing it with a QFlatMap (or
an unsorted vector, or a C array with the key as an index, or...).
Get the idea out of your collective heads that we just need QFlatMap and
everything will be solved. For some code, yes. Just like QMap is the
correct container for some code already. But s/QMap/QFlatMap/ is just as
wrong as using QMap just because you need an associative container was
in the first place.
More information about the Development