Joerg.Bornemann at qt.io
Wed Jun 12 13:26:56 CEST 2019
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
>> 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
More information about the Development