deploy: 00cac2e48d

2.Auto/item5.html

@@ -241,7 +241,7 @@ for(const std::pair<std::string, int>& p : m)
 <p>基于这些原因我建议你优先考虑<code>auto</code>而非显式类型声明。然而<code>auto</code>也不是完美的。每个<code>auto</code>变量都从初始化表达式中推导类型，有一些表达式的类型和我们期望的大相径庭。关于在哪些情况下会发生这些问题，以及你可以怎么解决这些问题我们在<a href="../1.DeducingTypes/item2.html">Item2</a>和<a href="../2.Auto/item6.html">6</a>讨论，所以这里我不再赘述。我想把注意力放到你可能关心的另一点：使用auto代替传统类型声明对源码可读性的影响。</p>
 <p>首先，深呼吸，放松，<code>auto</code>是<strong>可选项</strong>，不是<strong>命令</strong>，在某些情况下如果你的专业判断告诉你使用显式类型声明比<code>auto</code>要更清晰更易维护，那你就不必再坚持使用<code>auto</code>。但是要牢记，C++没有在其他众所周知的语言所拥有的类型推导（<em>type inference</em>）上开辟新土地。其他静态类型的过程式语言（如C#、D、Sacla、Visual Basic）或多或少都有等价的特性，更不必提那些静态类型的函数式语言了（如ML、Haskell、OCaml、F#等）。在某种程度上，这是因为动态类型语言，如Perl、Python、Ruby等的成功；在这些语言中，几乎没有显式的类型声明。软件开发社区对于类型推导有丰富的经验，他们展示了在维护大型工业强度的代码上使用这种技术没有任何争议。</p>
 <p>一些开发者也担心使用<code>auto</code>就不能瞥一眼源代码便知道对象的类型，然而，IDE扛起了部分担子（也考虑到了<a href="../1.DeducingTypes/item4.html">Item4</a>中提到的IDE类型显示问题），在很多情况下，少量显示一个对象的类型对于知道对象的确切类型是有帮助的，这通常已经足够了。举个例子，要想知道一个对象是容器还是计数器还是智能指针，不需要知道它的确切类型。一个适当的变量名称就能告诉我们大量的抽象类型信息。</p>
-<p>真正的问题是显式指定类型可以避免一些微妙的错误，以及更具效率和正确性，而且，如果初始化表达式的类型改变，则<code>auto</code>推导出的类型也会改变，这意味着使用<code>auto</code>可以帮助我们完成一些重构工作。举个例子，如果一个函数返回类型被声明为<code>int</code>，但是后来你认为将它声明为<code>long</code>会更好，调用它作为初始化表达式的变量会自动改变类型，但是如果你不使用<code>auto</code>你就不得不在源代码中挨个找到调用地点然后修改它们。</p>
+<p>事实是显式指定类型通常只会引入一些微妙的错误，无论是在正确性还是效率方面。而且，如果初始化表达式的类型改变，则<code>auto</code>推导出的类型也会改变，这意味着使用<code>auto</code>可以帮助我们完成一些重构工作。举个例子，如果一个函数返回类型被声明为<code>int</code>，但是后来你认为将它声明为<code>long</code>会更好，调用它作为初始化表达式的变量会自动改变类型，但是如果你不使用<code>auto</code>你就不得不在源代码中挨个找到调用地点然后修改它们。</p>
 <p><strong>请记住：</strong></p>
 <ul>
 <li><code>auto</code>变量必须初始化，通常它可以避免一些移植性和效率性的问题，也使得重构更方便，还能让你少打几个字。</li>

print.html

@@ -965,7 +965,7 @@ for(const std::pair<std::string, int>& p : m)
 <p>基于这些原因我建议你优先考虑<code>auto</code>而非显式类型声明。然而<code>auto</code>也不是完美的。每个<code>auto</code>变量都从初始化表达式中推导类型，有一些表达式的类型和我们期望的大相径庭。关于在哪些情况下会发生这些问题，以及你可以怎么解决这些问题我们在<a href="2.Auto/../1.DeducingTypes/item2.html">Item2</a>和<a href="2.Auto/../2.Auto/item6.html">6</a>讨论，所以这里我不再赘述。我想把注意力放到你可能关心的另一点：使用auto代替传统类型声明对源码可读性的影响。</p>
 <p>首先，深呼吸，放松，<code>auto</code>是<strong>可选项</strong>，不是<strong>命令</strong>，在某些情况下如果你的专业判断告诉你使用显式类型声明比<code>auto</code>要更清晰更易维护，那你就不必再坚持使用<code>auto</code>。但是要牢记，C++没有在其他众所周知的语言所拥有的类型推导（<em>type inference</em>）上开辟新土地。其他静态类型的过程式语言（如C#、D、Sacla、Visual Basic）或多或少都有等价的特性，更不必提那些静态类型的函数式语言了（如ML、Haskell、OCaml、F#等）。在某种程度上，这是因为动态类型语言，如Perl、Python、Ruby等的成功；在这些语言中，几乎没有显式的类型声明。软件开发社区对于类型推导有丰富的经验，他们展示了在维护大型工业强度的代码上使用这种技术没有任何争议。</p>
 <p>一些开发者也担心使用<code>auto</code>就不能瞥一眼源代码便知道对象的类型，然而，IDE扛起了部分担子（也考虑到了<a href="2.Auto/../1.DeducingTypes/item4.html">Item4</a>中提到的IDE类型显示问题），在很多情况下，少量显示一个对象的类型对于知道对象的确切类型是有帮助的，这通常已经足够了。举个例子，要想知道一个对象是容器还是计数器还是智能指针，不需要知道它的确切类型。一个适当的变量名称就能告诉我们大量的抽象类型信息。</p>
-<p>真正的问题是显式指定类型可以避免一些微妙的错误，以及更具效率和正确性，而且，如果初始化表达式的类型改变，则<code>auto</code>推导出的类型也会改变，这意味着使用<code>auto</code>可以帮助我们完成一些重构工作。举个例子，如果一个函数返回类型被声明为<code>int</code>，但是后来你认为将它声明为<code>long</code>会更好，调用它作为初始化表达式的变量会自动改变类型，但是如果你不使用<code>auto</code>你就不得不在源代码中挨个找到调用地点然后修改它们。</p>
+<p>事实是显式指定类型通常只会引入一些微妙的错误，无论是在正确性还是效率方面。而且，如果初始化表达式的类型改变，则<code>auto</code>推导出的类型也会改变，这意味着使用<code>auto</code>可以帮助我们完成一些重构工作。举个例子，如果一个函数返回类型被声明为<code>int</code>，但是后来你认为将它声明为<code>long</code>会更好，调用它作为初始化表达式的变量会自动改变类型，但是如果你不使用<code>auto</code>你就不得不在源代码中挨个找到调用地点然后修改它们。</p>
 <p><strong>请记住：</strong></p>
 <ul>
 <li><code>auto</code>变量必须初始化，通常它可以避免一些移植性和效率性的问题，也使得重构更方便，还能让你少打几个字。</li>