[Development] Question about QCoreApplicationData::*_libpaths

Kevin Kofler kevin.kofler at chello.at
Wed Jan 20 20:48:42 CET 2016

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 

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

More information about the Development mailing list