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