问题优先

C++是否有一个优雅的解决方案来防止出于效率原因而不得不声明仅在循环外循环中使用的复杂对象变量？

详细说明

一位同事在我们的代码策略中提出了一个有趣的观点，它指出（释义）：始终对变量使用最小范围，并在第一次初始化时声明变量。

编码指南示例：

// [A] DO THIS
void f() {
  ...
  for (int i=0; i!=n; ++i) {
    const double x = calculate_x(i);
    set_squares(i, x*x);
  }
  ...
}
// [B] DON'T do this:
void f() {
  int i;
  int n;
  double x;
  ...
  for (i=0; i!=n; ++i) {
    x = calculate_x(i);
    set_squares(i, x*x);
  }
  ...
}

当然没有错，直到你从原始类型转移到对象。（对于某种接口）

例：

// [C]
void fs() {
  ...
  for (int i=0; i!=n; ++i) {
    string s;
    get_text(i, s); // void get_text(int, string&);
    to_lower(s);
    set_lower_text(i, s);
  }
  ...
}

在这里，字符串 s 将被破坏，它是每个循环周期的内存释放，然后每个周期get_text函数都必须为 s 缓冲区重新分配内存。

写

  // [D]
  string s;
  for (int i=0; i!=n; ++i) {
    get_text(i, s); // void get_text(int, string&);
    to_lower(s);
    set_lower_text(i, s);
  }

现在，S缓冲区中分配的内存将在循环运行之间保留，我们很可能会节省分配。

免责声明：请注意：由于这是循环，我们谈论的是内存分配，因此我认为通常考虑此问题并不为时过早。当然，在某些情况下和循环中开销无关紧要;但是n有唠叨的倾向，即比开发人员最初预期的更大，而代码有在性能确实很重要的上下文中运行的唠叨倾向。

无论如何，现在"通用"循环构造的更有效方法是违反代码局部性并声明复杂对象不合适，"以防万一"。这让我相当不安。

请注意，我考虑这样写：

// [E]
void fs() {
  ...
  {
    string s;
    for (int i=0; i!=n; ++i) {
      get_text(i, s); // void get_text(int, string&);
      to_lower(s);
      set_lower_text(i, s);
    }
  }
  ...
}

没有解决方案，因为可读性受到的影响更大！

进一步思考，get_text函数的接口无论如何都是非惯用的，因为无论如何，参数都是昨天的，并且"好"接口将按值返回：

  // [F]
  for (int i=0; i!=n; ++i) {
    string s = get_text(i); // string get_text(int);
    to_lower(s);
    set_lower_text(i, s);
  }

在这里，我们不为内存分配支付双倍的费用，因为极有可能通过 RVO 从返回值构造s，因此对于 [F]，我们支付的分配开销与 [C] 相同。但是，与 [C] 情况不同，我们无法优化此接口变体。

所以底线似乎是使用最小范围（可能）损害性能并使用干净的接口，_{我至少认为按值返回比 out-ref-param 的东西会}阻止优化机会要干净得多——至少在一般情况下。

不在于有时为了提高效率而不得不放弃干净的代码，问题在于一旦开发人员开始发现这种特殊情况，整个编码指南（参见 [A]、[B]）就会失去权威。

现在的问题是：见第一段