[Development] Views

[Joerg Bornemann]

On 6/12/19 10:28 AM, Mutz, Marc via Development wrote:
> 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.

I have to agree with Marc here. *Every* replacement must be checked 
manually whether the simple s/QMap/QFlatMap/ suffices or a more involved 
change is necessary.

I believe many cases would be easily portable, but there will still be 
spots left where a raw sorted vector is the right approach - or another 
abstraction.


Joerg