Qt容器count()结果缓存必要性及编译器优化疑问

这个问题问得很好！很多Qt初学者都会对这种“缓存容器大小”的写法感到困惑，我来一步步拆解你的疑问：

编译器真的会优化循环中的count()调用吗？ #

首先得明确一个关键前提：QList的count()是O(1)操作——它内部直接维护了一个记录元素数量的成员变量，调用count()只是简单读取这个值，完全没有遍历容器的开销。

那编译器能不能把循环里重复的items.count()优化成只调用一次？分两种情况看：

• 如果循环体内绝对不会修改items（比如你的代码里soSomething()没有任何逻辑会改动这个QList的内容），现代编译器（GCC、Clang、MSVC等，只要开了O2及以上优化级别）完全可以识别出items.count()是“循环不变量”，自动把它提到循环外面，只计算一次。
• 但如果编译器无法确定循环体是否会修改items（比如soSomething()是一个外部黑盒函数，或者存在间接修改容器的可能），它就不敢做这个优化——因为一旦容器大小在循环中变化，重复调用count()的结果会不一样，优化就会导致逻辑错误。

不过在你的这段代码里，items是collidingItems()返回的临时对象拷贝，循环里几乎不可能被修改，所以编译器大概率会自动优化掉重复的count()调用。

缓存count()的值到底值不值得？ #

结论是：对于QList这种O(1)获取大小的容器，缓存的性能收益微乎其微，几乎可以忽略。

那为什么会有人写这种代码？主要有几个原因：

• 习惯使然：很多程序员是从旧时代过来的，早年有些容器（比如C++98里的std::list，它的size()曾经是O(n)操作）或者自定义容器的size()方法有遍历开销，缓存值是必要的性能优化。这个习惯保留到了现在。
• 防御性编程：怕以后代码改动时，不小心在循环体里修改了容器的大小，或者替换成了一个size()是O(n)的容器，提前缓存可以避免潜在的性能问题。
• 代码可读性：有些人觉得把total变量提出来，能更清晰地看到循环的总次数，逻辑更直观。

但回到你的场景：哪怕面对超大容器，QList的count()依然是O(1)，所以即使容器有几百万个元素，每次调用count()也只是读一个整数，耗时可以忽略。这种写法更多是个人风格问题，而非必要的优化。如果你的代码风格更倾向简洁，直接写i < items.count()完全没问题；如果觉得缓存后更清晰，也可以写，不会有任何坏处。

内容的提问来源于stack exchange，提问作者k.S