我指出的一个危险是在引用方面。 如。

MyBigObject& ref_to_big_object= big_object;
auto another_ref = ref_to_big_object; // ?

问题是，在这种情况下，another_ref实际上不是一个引用，它是MyBigObject而不是MyBigObject&。你最终复制了一个大对象而没有意识到它。

如果你直接从一个方法中得到一个引用，你可能不会考虑它实际上是什么。

auto another_ref = function_returning_ref_to_big_object();

你需要"auto&"或者"const auto&"

MyBigObject& ref_to_big_object= big_object;
auto& another_ref = ref_to_big_object;
const auto& yet_another_ref = function_returning_ref_to_big_object();

在c++和超越2012的Ask Us Anything小组中，Andrei Alexandrescu、Scott Meyers和Herb Sutter就何时使用和不使用auto进行了一次精彩的交流。跳到25:03分钟进行4分钟的讨论。这三位演讲者都给出了很好的观点，应该记住什么时候不使用auto。

我非常鼓励人们得出自己的结论，但我的结论是在任何地方都要使用auto，除非:

这会影响可读性 关心自动类型转换(例如，从构造函数，赋值，模板中间类型，整数宽度之间的隐式转换)

自由地使用explicit有助于减少对后者的关注，这有助于最大限度地减少前者成为问题的时间。

换句话说，Herb说，“如果你不做X, Y和Z，用auto。了解X, Y和Z是什么，然后在其他地方使用auto。”

c++程序的一个主要问题是允许你使用未初始化的变量。这导致了我们讨厌的非确定性程序行为。应该注意的是，现代编译器现在抛出适当的/message警告消息，如果程序累了使用它。

为了说明这一点，考虑下面的c++程序:

int main() {
    int x;
    int y = 0;
    y += x;
}

如果我使用现代编译器(GCC)编译这个程序，它会给出警告。这样的警告可能并非如此 如果我们使用的是真正复杂的产品代码，这是非常明显的。

main.cpp:在函数'int main()'中: Main.cpp:4:8:警告:'x'在此函数中未初始化 (-Wuninitialized) Y += x; ＾

================================================================================= 现在如果我们改变我们的程序，使用auto，然后编译，我们得到如下:

int main() {
    auto x;
    auto y = 0;
    y += x;
}

main.cpp:在函数'int main()'中: Main.cpp:2:10:错误:声明'auto x'没有初始化式 汽车x; ＾

对于auto，不可能使用未初始化的变量。如果我们开始使用auto，这是我们可以(免费)获得的主要优势。

c++专家Herb Shutter在他的CppCon14演讲中解释了这个概念和其他伟大的现代c++概念:

回归基本!现代c++风格要点

我指出的一个危险是在引用方面。 如。

MyBigObject& ref_to_big_object= big_object;
auto another_ref = ref_to_big_object; // ?

问题是，在这种情况下，another_ref实际上不是一个引用，它是MyBigObject而不是MyBigObject&。你最终复制了一个大对象而没有意识到它。

如果你直接从一个方法中得到一个引用，你可能不会考虑它实际上是什么。

auto another_ref = function_returning_ref_to_big_object();

你需要"auto&"或者"const auto&"

MyBigObject& ref_to_big_object= big_object;
auto& another_ref = ref_to_big_object;
const auto& yet_another_ref = function_returning_ref_to_big_object();

是的，它可能被过度使用而损害可读性。我建议在这样的情况下使用它:确切的类型很长，或者无法表达，或者对可读性不重要，并且变量的寿命很短。例如，迭代器类型通常很长，不重要，所以auto可以工作:

   for(auto i = container.begin(); i != container.end(); ++i);

这里的Auto不会影响可读性。

另一个例子是解析器规则类型，它可能很长很复杂。比较:

   auto spaces = space & space & space;

with

r_and_t<r_and_t<r_char_t<char>&, r_char_t<char>&>, r_char_t<char>&> spaces = 
   space & space & space;

另一方面，当类型是已知的并且是简单的，如果显式地声明它会更好:

int i = foo();

而不是

auto i = foo();

TL;DR:见底部的经验法则。

公认的答案包含以下经验法则:

当第一眼不知道如何写类型，但表达式右边的类型很明显时，请使用auto。

但我想说这太严格了。有时我并不关心类型，因为语句已经提供了足够的信息，而无需我花时间去弄清楚类型。这是什么意思呢?考虑一下一些答案中出现的例子:

auto x = f();

是什么使这个例子滥用auto?是我不知道f()的返回类型吗?好吧，如果我知道的话可能会有帮助，但是-这不是我主要关心的。更大的问题是x和f()是没有意义的。如果我们有:

auto nugget = mine_gold();

相反，我通常不关心函数的返回类型是否明显。读这个语句，我知道我在做什么，我对返回值的语义有足够的了解，所以我不觉得我还需要知道它的类型。

所以我的回答是:只要编译器允许，就使用auto，除非:

You feel the variable name together with the initialization / assignment expression do not provide enough information about what the statement is doing. You feel the variable name together with the initialization / assignment expression provides "misleading" information about what the type should be - i.e., if you had to guess what comes instead of the auto you would be able to make a guess - and it would be wrong, and this false assumption has repercussions later in the code. You want to force a different type (e.g. a reference).

还有:

在用具体类型替换auto之前，最好给出一个有意义的名称(当然不包含类型名)。