Question

在'doSomething'函数中，每次递增时都会将'number'带入缓存中吗？

编辑：我问，因为我遇到了Mike Acton的一些评论。他发表了this评论，然后建议使用本地注册。 Here是整个评论集。

    class a
    {
    public:
        int number;
        void doSomething();
    }

    void a::doSomething()
    {
        for (int i = 0; i < 50; ++i)
        {
            number += i;
        }
    }

    int main()
    {
        a;
        a.doSomething();
        return 0;
    }

Answer 1

最有可能的是，如果实际发出了循环，它将在第一次访问时被带入高速缓存，并保持在那里直到循环结束（再次，可能;它不像编译器对此具有特定的控制权，通常在普通存储器访问中透明地引入高速缓存。

请注意，此处的编译器也允许将代码转换为：

int n = number;
for (int i = 0; i < 50; ++i)
{
    n += i;
}
number = n;

因为循环中没有函数调用可能会看到number的中间状态（也没有强制中间状态对其他线程可见的内存屏障）。 n这里可能是一个寄存器，因此缓存不相关。

最后，几个现代编译器实际上将其优化为：

number += 1225;

所以没有那么多的缓存访问让人担心。

Answer 2

您在询问幻灯片45，但我会评论所有这些幻灯片。

幻灯片7：此处没有float-to-int转换。有一个int-to-float转换。
幻灯片11：没有疯狂的分支＆＃39;这里。我肯定会在源代码冗余的基础上省略else，但是没有像样的编译器会为它们生成分支。即使它确实如此，它们也永远不会被占用，所以它们只需要花费空间，而不是时间。
幻灯片12-16和17-20和21-23分别是单一投诉，而不是五/四/三，关于申请的语义，而不是一般原则。
幻灯片24-28说明了“＃good;＆＃34;＆＃34; good＆＃34;用[S]＆＃39; virtual很难得到＆＃39;。
幻灯片29是另一个无聊的咆哮。使用名称作为清单常量，尤其是 Universe的物理常量或数学常量没有任何问题。有关常见示例，请参阅PI。
幻灯片31与第12至23段幻灯片完全矛盾。
幻灯片32可能是毫无意义的微优化。 m是一个归纳变量，因此很有可能它已被编译器优化掉了。
幻灯片35似乎也与第12至23段幻灯片相矛盾。
幻灯片45：在内部循环中写入类成员没有任何问题，而隐含的使用寄存器或局部变量的建议（无论此处是什么）都有空间成本和语义风险。
幻灯片46：几十年来，C和C ++编译器忽略了register声明。鉴于有关语义约束的足够信息，编译器完全能够为自己进行优化。
幻灯片47-50：难以理解。
幻灯片51：可能的语义变化，未解决。
幻灯片53-4：哦，这个评论没用。 enum值本身并不是[e]不需要的分支＆＃39;。需要进行适当的解释而不提供。
幻灯片55：引用不是“无意义的”，而且也没有返回。
幻灯片56：难以理解。
幻灯片57：不专业且令人反感。

我不认为我已经阅读过20多年的垃圾了。我必须严肃质疑每个问题使用四个和五个便利贴的人的心态。而且他很少提供实际的解决方案。

每次从成员函数访问类数据时都会将其带入内存吗？

2 个答案: