本文翻译自《effective modern C++》，由于水平有限，故无法保证翻译完全正确，欢迎指出错误。谢谢！
啊，简单愉快的代码：
inr x;
等等，讨厌！我忘了初始化x，所以它的值是不确定的。可能，它可能被初始化成了0，这取决于你的编译环境。哎。
不要紧，让我们简单并愉快地声明一个局部变量，通过解引用一个iterator来初始化它：
template<typename It>
void dwim(It b, It e)
{
while(b != e){
typename std::iterator_traits<It>::value_type
currValue = *b;
...
}
}
呸，真的要用“typename std::iterator_traits
好的，再看一个简单愉快的例子（第三个了）：愉快地声明一个局部变量，让他的类型是一个闭包。噢，对的，闭包的类型只有编译器知道，因此不能被写出来，哎，讨厌。
讨厌，讨厌，讨厌！C++编程，并不是一段愉快的经历（它本应该是愉快的）。
好的吧，它曾经不是。但是在C++11中，由于auto提供的好意，所有的这些麻烦都离去了。auto变量从初始化表达式中推导它们的类型，所以它们必须被初始化。这意味着，当你快速行驶在现代C++的超级高速公路上时，你能和变量未初始化问题挥手再见了：
int x1; //可能未初始化
auto x2; //错误！需要初始化表达式
auto x3 = 0; //好的，x的值是良好定义的
通过对iterator解引用来声明局部变量时，这个高速公路没有之前那样的困难：
template<typename It> //和之前一样
void dwim(It b, It e)
{
while(b != e){
auto currValue =*b;
...
}
}
并且，因为auto使用类型推导（看 Item 2），它能表示只有编译器知道的类型：
auto derefUPLess =
[](const std::unique_ptr<Widget>& p1,
const std::unique_ptr<Widget>& p2)
{ return *p1 < *p2; };
非常酷，在C++14中，温度进一步下降（事情变得更简单），因为lambda表达式的参数可以涉及auto：
auto derefLess =
[](const auto& p1,
(const auto& p2)
{ return *p1 < *p2; };
虽然很酷，你可能觉得我们不需要使用auto来声明一个变量来包含闭包，因为我们可以使用std::function对象。这是对的，我们能这么做，但是事情并不是你想的那样。有的读者可能在想“什么是std::function对象” ，那就让我们先来理清这个对象把。
std::function是C++11标准库中的模板，这个模板扩张了函数指针的概念。函数指针只能指向函数，但是，std::function对象能指向所有可调用对象。也就是，所有能像函数一样用“()”调用的东西。就像你创建函数指针的时候，必须明确指向函数的类型（也就是你想指向的函数的签名），当你传入std::function对象时，你必须明确你引用的函数的类型。你通过std::function模板的参数来做到这一点。举个例子，为了声明一个能调用任何下面函数签名的std::function对象，
bool(const std::unique_ptr<Widget>&,
const std::unique_ptr<Widget>&)
你会这么写：
std::function<bool(const std::unique_ptr<Widget>&,
const std::unique_ptr<Widget>&)> func;
因为lambda表达式产生一个可调用对象，所以闭包能被存放在std::function对象中。这意味着我们能不使用auto就声明一个C++11版本的derefUpLess：
std::function<bool(const std::unique_ptr<Widget>&,
const std::unique_ptr<Widget>&)>
derefUpLess = [](const std::unique_ptr<Widget>& p1,
const std::unique_ptr<Widget>& p2)
{ return *p1 < *p2; };
你要知道下面的要点，就算把这冗长的语法和重复的变量类型放在一边，使用std::function和使用auto也不是一样的。一个用auto声明的变量存放和闭包同样类型的闭包，并且只使用和闭包所要求的内存一样多的内存。std::function声明的变量存放了一个闭包，这个闭包是std::function模板的实例，并且他对任何给出的签名都需要调整大小。这个大小可能不够一个闭包来存储，当遇到这样的情况时，std::function的构造函数将申请堆内存来存储闭包。结果就是相比auto声明的对象，std::function对象通常要使用更多的内存。再考虑下实现的细节，由于inline函数的限制，间接函数的调用，调用闭包时，通过std::function对象调用总是比通过auto声明的对象调用要慢。换句话说，std::function方法通常比auto方法更大更慢，并且可能产生内存溢出异常。更好的是，就像你在上面的例子中看到的那样，写”auto“要做的工作完全少于写std::function实例类型。在auto和存储闭包的std::function对比中，auto完胜了。（相似的争论会出现在std::bind函数的返回值的存储中，同样可以使用auto或std::function，但是在Item 34中，我尽全力来让你信服,无论如何使用lambdas表达式来代替std::bind）
auto的优点不局限于避免未初始化的变量，冗长的变量声明和直接闭包的声明。它的另外一个能力就是能避免我们由于使用“类型快捷方式”（“type shortcuts”）而造成问题。这里给出一些你看起来会做的事，你可能会这么写：
std::vector<int> v;
...
unsigned sz = v.size();
v.size()的官方返回类型是std::vector
使用auto能保证你不会遇到这样的问题：
auto sz = v.size(); //sz的类型是std::vector<int>::size_type
难道你还不肯定使用auto的智慧？那再看看这代码：
std::unordered_map<std::string, int> m;
...
for(const std::pair<std::string, int>& p : m)
{
... //用p做些事
}
这看起来很有道理，但是这里存在一个问题，你看到了吗？
想想看什么需要记住的东西遗漏了，std::unordered_map的键的部分是const的，所以在hash table（std::unordered_map的存储类型）中的std::pair的类型不是std::pair<std::string, int>，它是std::pair<const std::string, int>(译注：
//这是stl源码书中看到的hash_map的类型定义， 可以看到
//它的类型是pair<const Key, T>
typedef hashtable<pair<const Key, T>, Key, HashFcn,
select1st<pair<const Key, T>, EqualKey, Alloc> ht; )。 但是这不是上面循环中的变量p的声明类型。对于这个结果，编译器将努力去找到一个方法来转换std::pair<const std::string, int>对象（也就是hash table的内容）到std::pair<std::string, int>对象（p声明的类型）。通过拷贝m里的对象，创造一个个临时对象，然后把p引用绑定到临时对象上去，p就成功地被创造出来了。在每一次循环结尾，临时对象将被销毁。如果你写下这样的循环，你会被它的效率所震惊，因为大概你想做的只是简单地把p的引用绑定到m的每个元素p上。
这样无意识的类型不匹配能通过auto来消除：
for(const auto& p : m)
{
... //as before
}
这不仅更加有效率，也更容易写。更好的是，这个代码有一个非常吸引人的特征，那就是如果你获取p的地址，你肯定能取到一个指向存在于m中的p的指针，但是如果不使用auto，你会取到一个指向临时变量的指针，而且这个临时变量在每一次循环结尾会销毁。
最后的两个例子—当你应该写std::vector
因此，这里有很多原因来让你选择auto而不是显式的类型声明。到目前为止，auto不是完美的。对于每个auto变量，类型是从它的初始化表达式推导来的，并且一些初始化表达式拥有的类型不是我们能预料到以及想要的。会出现这样情况的情景，以及你要如何做已经在Item 2和Item 6中讨论了，所以我在这不会涉及他们了。作为替换，我将把我的注意力放在在你使用传统的类型声明时，你使用auto会有什么不同之处：生成的源代码的可读性。
首先，做一下深呼吸并且放轻松。auto是可选的，不是必需品。如果经过你的专业判断，使用明确的类型声明能使你的代码更清晰，可维护性更好，或其他好处，你可以继续自由地使用明明确的类型声明。但是把这记在心里，在编程语言世界中众所周知的是，C++采取的类型推导不是新的东西。其他静态类型的语言（比如C#，D，Scala，Visual Basis）或多或少也有这样的特性，更不用说那些静态类型的函数式语言（比如ML，Haskell，OCaml，F#，等等）。这部分，由于动态语言（比如Perl，Python，和Ruby）的成功，类型很少被显式地写出来。软件开发社区对类型推导有很深的经验，并且也证明了这技术可以用在创造和维护大型的，企业级的代码中。
由于auto的使用，在源文件中，只通过看一眼无法明确对象的类型，一些开发者就感到困扰了。然而，IDE有显示这些对象类型的能力，让这个问题缓和了一些（可以参考Item 4中说的IDE类型显示的问题），并且，在很多情况下，一个比较抽象的对象类型和明确的对象类型是一样有用的。举个例子，你不需要知道具体的类型，只要知道一个对象是一个容器，或一个计数器，或一个智能指针，这常常就够了。假设使用良好的名字，这些抽象类型的信息就已经能在名字中得知了。
事实是，不管是在正确性上还是效率上，写出明确的类型常常起到的作用很小，却造成更多的问题。更重要的是，auto类型的变量能在初始化的表达式改变时自动改变，这意味着使用auto能简化重构。举个例子，如果一个函数的返回类型声明为了int，但是之后你觉得使用long会更好，在你下次编译程序的时候，如果你把调用这个函数的结果存在auto类型变量中，auto类型变量会自动改变自己的类型。如果结果被存放在明确声明的类型中，你就需要找到所有调用这个函数的地方并且手动修改它们。
你要记住的事
-
比起显式类型声明，auto变量必须被初始化，它常常免于由类型不匹配造成的可移植性和效率的问题，它能简化程序的重构，并且通常只需要写的更少的代码。
-
auto类型变量的陷阱在Item 2和Item 6中讨论。