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 _______________________________________________ Development mailing list Development@qt-project.org https://lists.qt-project.org/listinfo/development
