我们现在应该总是依赖编译器优化吗？

如何解决我们现在应该总是依赖编译器优化吗？

过去写这样的代码是一个好习惯：

int var = 0,var1 = 0; //declare variables outside the loop not to create them every time we go into for
auto var2 = somefunc(/*some params*/); 
for (int i = 0,size = vec.size(); i < size; ++i)
{
    //do some calculation,use var,var1,var2
}

但是现在所有（？）现代编译器都会为你优化它，如果你写：

for (int i = 0; i < vec.size(); ++i)
{
    //do something
    int var = /*some usage*/; //declare where you need it for better readability
    //do something     
    int var1 = /*some usage with call to somefunc(/*some params*/) */; //declare where you need it for better readability
    //do something
}

编译器会对其进行优化，使其与第一个片段相同（甚至更好）。

那么，我们是否应该一直依赖编译器来优化变量分配等，编写其他程序员更容易阅读的代码？

免责声明：这不是基于意见的问题。我没有很多编译器的经验，我也没有使用编译器优化选项的经验，所以我希望有经验的人在这里回答，比如“我用过很多编译器，是的，现在他们是很聪明，我们不需要考虑在哪里声明变量”，或者“哦，我遇到了一些没有做这些优化的编译器，所以我们仍然需要考虑它”，或者其他什么关于优化选项的使用体验。

解决方法

变量不会像您想象的那样“创建”。实际上，它们要么是堆栈上的位置，要么是为特定目的保留的寄存器。在大多数情况下，在循环内确定它们的范围绝对是零成本。

与往常一样，如果您想确定，请查看程序集输出。

如果您习惯于 Python、Ruby 或 JavaScript 等语言，其中创建变量是一项具有实际成本的操作，这可能就是您这么想的原因，但在优化的 C++ 构建中，这是一个完全不同的游戏，与任何通过编译器传递的语言一样，甚至是 JIT。

,

调用 somefunc 将是一个脆弱的优化，如果它发生。

但一般来说，为了可读性而写，避免过早的悲观，在写完之后确定性能瓶颈在哪里，并在性能瓶颈所在的地方花费精力进行可衡量的改进。

难读的代码很难调试，很难改正，也很难改进。与首先编写代码相比，您通常会花费更多时间在所有这些上。

平凡类型的变量，如 int 或 double，在调试构建之外不存在您可能想象的方式。更复杂的类型可以有更基本的存在，因为创建/销毁它们的位置很重要。但是编译器在不断改进，所以即使在这里担心代码是一个瓶颈也是一个糟糕的计划。

,

编译器优化是性能安全网。换句话说，它们不是您所依赖的东西。对于不知道代码中的惩罚的程序员来说，它们是一种后备。

话虽如此，默认情况下您不应该信任优化，因为并非所有编译器都具有相同的行为。在同样的意义上，任何事物的两个实现都不会共享相同的行为。如果您在嵌入式系统中工作，尤其是在异国情调的硬件上工作，您可能会被一个极简的 C 编译器困住，该编译器对您几乎没有帮助。

另外，仅仅因为某些东西被优化了，并不一定意味着你必须牺牲可读性。

,

智能编译器总是不错的选择，因为它（可能）会改进您的代码。但是，如果您有不同的构建选项，例如调试和发布或生产构建，它有时也会带来痛苦。因此，您必须明智地选择，因为您的要求可能是 Oh Yes！我知道我在做什么。