[Development] Views

Mutz, Marc 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
>>     discussion.
> Having the thing COW makes the porting simpler at the cost of 
> suboptimal
> 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 mailing list