我一直在使用c++ 11标准中提供的新的auto关键字来处理复杂的模板类型，我相信它就是为这个目的设计的。但我也用它来做以下事情:
auto foo = std::make_shared<Foo>();
更令人怀疑的是:
auto foo = bla(); // where bla() return a shared_ptr<Foo>
我还没有看到很多关于这个话题的讨论。auto似乎被滥用了，因为类型通常是一种文档和完整性检查的形式。你在使用auto方面的界限在哪里，这个新功能的推荐用例是什么?
澄清一下:我并不是在寻求哲学观点;我要求标准委员会对这个关键字的预期使用，可能还会对如何在实践中实现预期使用发表评论。
当前回答
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之前，最好给出一个有意义的名称(当然不包含类型名)。
其他回答
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之前，最好给出一个有意义的名称(当然不包含类型名)。
在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。”
什么汽车?
它告诉编译器根据变量的初始值推断(确定)变量的数据类型。它使用类型演绎。
auto应该用在哪里?
当你对变量的类型不感兴趣时 想要使用它。 当你想要避免非常长和丑陋的typename。 当你不确定自己的类型时。 当你不想在你的代码中看到未初始化的变量。 Auto强制你初始化一个变量，因此你不能忘记做 那
当它不应该使用或缺点的自动
参考它的功能，auto可能会错误地推断类型，1 这种情况是
Std::vector<bool> vec(10,0); Auto x = vec[2]; Bool y = vec[2]; Std::cout << typeid(x).name() << "\n"; Std::cout << typeid(y).name() << "\n";
g++ 10.2上的输出令人惊讶:
St14_Bit_reference
b
如果你想让你的代码可读&，不应该使用它 对其他人来说是可以理解的。它隐藏了数据类型的可见性 来自读者。
我指出的一个危险是在引用方面。 如。
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关键字。例如，使用:
my_multi_type::nth_index<2>::type::key_type::composite_key_type::
key_extractor_tuple::tail_type::head_type::result_type
要在boost::multi_index中获取复合键类型，即使您知道它是int。你不能只写int，因为它将来可能会被改变。在这种情况下我会写auto。
因此，如果auto关键字在特定情况下提高了可读性，那么就使用它。当读者很清楚auto所代表的类型时，可以使用auto。
下面是一些例子:
auto foo = std::make_shared<Foo>(); // obvious
auto foo = bla(); // unclear. don't know which type `foo` has
const size_t max_size = 100;
for ( auto x = max_size; x > 0; --x ) // unclear. could lead to the errors
// since max_size is unsigned
std::vector<some_class> v;
for ( auto it = v.begin(); it != v.end(); ++it )
// ok, since I know that `it` has an iterator type
// (don't really care which one in this context)
