在循环后面声明变量还是在循环里面声明变量？

新评论
  
   string st = "";
   for (int i = 0; i < 1000; i++)
   {
      st = i;
      ...
   }

或

   for (int i = 0; i < 1000; i++)
   {
      string st = i;
      ...
   }

鉴于mql5编译器的所有优化，有什么区别吗？

 
pivalexander:

或

鉴于mql5编译器的所有优化，有什么区别吗？

在编译方面没有区别，所以请随意使用第二个选项。
 

就个人而言，我更喜欢前者。

以防万一。编译器可能很聪明，不会每次都分配内存，但在第一种情况下，我明确指定，但在第二种情况下，这是编译器隐含的结果，因为语言的逻辑是在一个块内创建一个变量，并在退出该块时将其删除。

而将int等同于字符串而不进行转换是不好的做法。

 
pivalexander:

鉴于mql5编译器的所有优化，有什么区别吗？

不要听信没有区别的说法。只使用第一个选项，是有区别的。不过我还没有研究过麦克尔公司的Disassm。

 
Georgiy Merts:

就个人而言，我更喜欢前者。

以防万一。编译器可能很聪明，不会每次都分配内存，但在第一种情况下，我明确指定，但在第二种情况下，这是编译器隐含的结果，因为语言的逻辑是在块内创建一个变量，在退出块时必须删除。

而将int等同于字符串而不进行转换是不好的做法。

乔治是对的，它不能保证。

我们得到了一个从 "数字 "到 "字符串 "的隐式转换的翘曲。


而这正是我们摆脱不确定性和扭曲的方法。

for (int i = 0; i < 1000; i++)
   {
      static string st = IntegerToString(i);
      ...
   }
 
Georgiy Merts:

就个人而言，我更喜欢前者。

以防万一。编译器可能足够聪明，不会每次都分配内存，但在第一种情况下，我明确指定，但在第二种情况下，这是编译器工作的隐性结果

你在开玩笑吗？ 对编译器来说，这是一个微不足道的情况，没有什么好谈的。 你可能对它如此偏执，以至于你只需要用汇编程序编码。 虽然现在连这都已经变得毫无意义了。 你必须努力去战胜现代编译器的优化。

p.s. 也许我对字符串缓冲器 的琐碎性有点激动。但在MQL中，不仅在循环内部，甚至在函数调用之间，它都能保证被保存。这个话题在这里不止一次讨论过
 

不要听他们的，他们会在这里告诉你很多东西的 ))

// c++
#include <iostream>
#include <string>
using namespace std;

void* operator new(size_t sz) {
    void *ptr = std::malloc(sz);
    if (ptr)
        return ptr;
    else
        throw std::bad_alloc{};
}


int main() {
        for (uint i = 0;  i < 3;  ++ i) {
                string s;
                char buf[10];
                sprintf(buf, "%u", i);
                s = "sfjhidfsrtea111";
                s += buf;
                cout << s << '\n';
        }
}

我编译了gcc -O3，在调试器下运行，在操作者new上设置断点，得到三个调用。与clang相同。

注意：如果字符串被从循环中取出，我就会得到一个调用。

 
Alexey Navoykov:

你在开玩笑吗？ 对于编译器来说，这是一个微不足道的情况，没有什么好谈的。 如果你如此偏执，你可以纯粹用汇编程序写代码。 但即使是这样，如今也变得毫无意义了。 你必须努力去击败现代编译器的优化。

p.s. 也许我对字符串缓冲器 的琐碎性有点激动。但在MQL中，不仅在循环内部，甚至在函数调用之间，它都能保证被保存。这个话题在这里不止一次讨论过

不，我没有。

当然，在这种情况下，一个正常的编译器应该把循环内的变量声明带到外部。

我只是认为你应该永远相信编译器，相信自己。编译器的标准是，局部变量在声明时被创建，在声明它的块退出时被删除。因此，你应该首先关注这一原则，而不是等待编译器为你改进你的代码。

这不是效率的问题（现代编译器确实能给出非常高质量的代码），而是程序员的思维方案。 当我看Kodobase的源代码时，我经常想知道它们包含了多少简单的、但有潜在危险的小缺陷。在这种情况下，这还不是很关键，最多可能发生的是程序工作得慢一点。 真正的错误可能要棘手得多。

 
Vict:

不要听他们的，他们会在这里告诉你很多东西的 ))

我编译了gcc -O3，在调试器下运行，在操作者new上设置断点，得到三个调用。与clang相同。

因此，如果字符串被从循环中取出，我就会得到一个调用。

它不可能不这样做，因为你自己通过断点干扰了优化。 优化的本质是它不应该改变算法的逻辑。这就是为什么它不能被明确检测出来。 如果那里有一个断点，编译器当然无权把这段代码剪掉。 你期望编译器能跳过断点 吗？)

你只能通过编译代码或测量其性能来检测优化，所以这是你应该做的第一件事。冷静下来 )

 
等待测量)
 
Alexey Navoykov:

它不可能不这样做，因为你自己通过断点干扰了优化。 优化的要点是，它不能改变算法的逻辑。这就是为什么它不能被明确地检测出来。 如果那里有一个断点，编译器自然无权把这段代码剪掉。 你是否想到编译器可能会跳过断点？)

你只能通过编译代码或测量其性能来检测优化，所以这是你应该做的第一件事。冷静下来 )

伙计，这简直是疯狂的蠢事，有什么好评论的，完全是对调试器工作原理的误解。

关于速度--内存管理器不是那么愚蠢的，也不是会问操作系统的事实，可能会过度使用早期分配的。一般来说，怎么用就怎么用，由你自己决定。但你不应该让别人相信这一点，至少在你提供具体证据之前，他们在哪里？

1234567891011
新评论