引用类型转换运算符：自找麻烦？

Question

当我使用 g++ 编译以下代码时，

class A {};

void foo(A&) {}

int main()
{
  foo(A());
  return 0;
}

我收到以下错误消息：

> g++ test.cpp -o test     
test.cpp: In function ‘int main()’:
test.cpp:10: error: invalid initialization of non-const reference of type ‘A&’ from a temporary of type ‘A’
test.cpp:6: error: in passing argument 1 of ‘void foo(A&)’

经过一番反思，这些错误对我来说很有意义。 A() 只是一个临时值，而不是堆栈上的可分配位置，因此它似乎没有地址。 如果它没有地址，那么我就无法保留对它的引用。 好的。

可是等等！ 如果我将以下转换运算符添加到类 A 中，

class A
{
public:
  operator A&() { return *this; }
};

那么一切都很好！ 我的问题是这是否安全。 当 A() 被构造为临时值时，this 到底指向什么？

这一事实给了我一些信心。

void foo(const A&) {}

可以根据 g++ 和我使用过的所有其他编译器接受临时值， const 关键字始终可以被丢弃，因此如果 const A& 参数和 A& 参数之间存在任何实际语义差异，我会感到惊讶。代码>参数。 所以我想这是问我的问题的另一种方式：为什么编译器认为对临时值的 const 引用是安全的，而非 const 引用则不然？

Answer 1

这并不是说地址不能被获取（编译器总是可以命令将其推入堆栈，这是通过 ref-to-const 实现的），这是程序员意图的问题。 对于采用 A& 的接口，它表示“我将修改此参数中的内容，以便您可以在函数调用后读取”。 如果您将其传递为临时值，那么它“修改”的内容在该函数之后不存在。 这（可能）是一个编程错误，因此是不允许的。 例如，考虑一下：

void plus_one(int & x) { ++x; }

int main() {
   int x = 2;
   float f = 10.0;

   plus_one(x); plus_one(f);

   cout << x << endl << f << endl;
}

这不会编译，但如果临时变量可以绑定到非常量引用，它会编译但会产生令人惊讶的结果。 在 plus_one(f) 中，f 将隐式转换为临时 int，plus_one 将获取 temp 并递增它，使底层浮点 f 保持不变。 当 plus_one 返回时，它不会有任何效果。 几乎可以肯定这不是程序员的意图。

---

规则有时确实会混乱。 一个常见示例（此处进行了描述） ，正在尝试打开一个文件，打印一些内容，然后关闭它。 您希望能够执行以下操作：

ofstream("bar.t") << "flah";

但您不能，因为运算符<< 采用非 const 引用。 您的选择是将其分成两行，或者调用返回引用非 const 的方法：

ofstream("bar.t").flush() << "flah";

Answer 2

当您将右值分配给 const 引用时，可以保证在引用被销毁之前临时不会被销毁。 当您分配给非常量引用时，不会做出此类保证。

int main()
{
   const A& a2= A(); // this is fine, and the temporary will last until the end of the current scope.
   A& a1 = A(); // You can't do this.
}

你不能随心所欲地安全地抛弃常量并期望事情能够正常进行。 const 和非常量引用有不同的语义。

Answer 3

有些人可能会遇到一个问题：MSVC 编译器（Visual Studio 编译器，已使用 Visual Studio 2008 进行验证）将毫无问题地编译此代码。 我们一直在一个项目中使用这种范例，该函数通常采用一个参数（要消化的一大块数据），但有时想要搜索该块并将结果返回给调用者。 另一种模式是通过采用三个参数来启用的——第二个参数是要搜索的信息（默认引用空字符串），第三个参数用于返回数据（默认引用所需类型的空列表）。

这种范例在 Visual Studio 2005 和 2008 中有效，我们必须重构它，以便构建并返回列表，而不是使用 g++ 进行编译的“由调用者拥有并变异”。

如果有一种方法可以将编译器开关设置为在 MSVC 中禁止这种行为或在 g++ 中允许这种行为，我会很高兴知道； MSVC 编译器的宽松性/g++ 编译器的限制性增加了移植代码的复杂性。