是否有编译器警告是 Visual Studio 2013 来检测复制而不是通过引用分配的引用

Question

特殊情况是，在一次大型重构之后，一位同事发生了变化

Foo & foo = DoSomething();

到

auto foo = DoSomething();

在哪里

Foo & DoSomething();

这导致了一个问题，即 foo 是通过复制而不是通过引用分配的。我们抓到了一个案子。我很好奇是否有编译器警告来检测上述代码导致的错误类型。

** 编辑 **

以下所有答案都包含有关应该做什么或不应该做什么的有用且有效的建议。需要明确的是，我正在寻找一些关于损坏发生后可以做什么的建议。一个很少使用的编译警告会很好。最后我们只是查看了代码差异，看看是否不止一次犯了同样的错误。

Answer 1

auto 的错误使用对性能非常不利。我已经对它的用法进行了多次讨论。

我的经验法则是尽可能使用auto && 变量。这遵循模板规则，成为转发引用。

可用于引用、常量引用和按值返回。 通过将其用作默认值，auto 和 auto & 清楚地表明您想要一个副本或者您想要一个可变引用。

也就是说，我不熟悉这种结构的编译器警告。我确实找到了一个看起来类似的 clang-tidy 检查：https://clang.llvm.org/extra/clang-tidy/checks/performance-unnecessary-copy-initialization.html

Answer 2

你的同事是个很淘气的男孩。首先请注意，Visual C++ 2013 不是 C++11 编译器，尽管它确实实现了一些 C++11 标准。值得注意的是，constexpr 不见了。

非正式地说，auto 确实不自动包含 &，所以它们本质上发生了变化

Foo & foo = DoSomething();

到

Foo foo = DoSomething();

这集中体现了在没有适当单元测试的情况下错误重构的危险。

正确的做法是保持代码不变。但是如果你公司的文化是所有新的和闪亮的东西都必须进入一个项目，那么最好的办法就是使用

auto&& foo = DoSomething();

要生成一组一次性的编译器警告，为什么不（暂时）删除复制构造函数并尝试构建项目？：

Foo(const Foo&) = delete;

Answer 3

一个好的经验法则可能是使用 decltype(auto) 而不是 auto 并为此进行心理训练。

在提供的示例中，它将使foo 的类型成为对Foo 的引用。