[Development] Question about QCoreApplicationData::*_libpaths

[Kevin Kofler]

Marc Mutz wrote:
> In those cases where it does matter, you'd return by const-&. Or an
> array_view. And no, that doesn't restrict your freedom to implement the
> function in any meaningful way, because you can always keep a caching
> mutable member to hold the result for the next call to the function
> (memoisation or however it's called), without any loss except the space
> required for the member.

All these are horrible and error-prone hacks that have obvious lifetime 
issues. You are complaining about Qt containers because the detaching can 
invalidate iterators. Well, the lifetime issues you introduce with the above 
proposed solutions are much worse! And a caching mutable member also 
destroys thread-safety (in addition to the obvious lifetime issue that the 
next call surprisingly invalidates your existing reference).

> What about non-arrays? By the time we get around to all this, there will
> be no containers other than array-compatible ones left, because nothing
> else will provide the required speed.

Sorry, but that is just utter nonsense. Replacing a hash table with an array 
will NOT make your code more efficient. Replacing a linked list with an 
array can also make your code slower if you do enough insertions/removals.

In the end, your real issue is not with the containers, but with the 
slowness of the malloc you use. Which means we need faster allocations, not 
containers that minimize allocations at all costs, including worse 
asymptotic algorithmic complexity.

        Kevin Kofler