Marc Mutz wrote:
> And if API consistency makes QVector have a prepend(), and QHash::iterator
> have it + n, something got out of hand...
I appreciate that Qt makes those operations possible (without having to code
them by hand). I know that operations such as QVector::prepend are not
efficient. That's clearly documented, and follows directly from even the
roughest description of how the class is implemented. (That said, for the
particular case of QVector::prepend, that could easily be fixed with the
same trick used in QList.) Sometimes, a given container is clearly the most
efficient for the parts of the application that run 99% of the time, having
a single O(n) operation in the remaining 1% is not going to hurt overall
efficiency.
As for adding n to a QHash::iterator, sure, most people won't use it, but
then it doesn't really hurt to have it there. And there may even be use
cases where it makes sense. (For example, to divide a hash table into n hash
tables minimizing the hash collisions. Taking every n-th element sounds like
a reasonable approach there.)
I consider STL's inconsistent APIs from one container to the other to be a
major annoyance. And it is not even always about efficiency: e.g.,
std::queue and std::priority_queue are implemented in the SAME header
<queue>, both are queues, yet std::queue calls its head element front(),
std::priority_queue calls it top().
Kevin Kofler
_______________________________________________
Development mailing list
Development@qt-project.org
http://lists.qt-project.org/mailman/listinfo/development
