Fix item5.md (#168)

最后一段开头的一句话原文是“The fact of the matter is that writing types explicitly often does little more than intro‐
duce opportunities for subtle errors, either in correctness or efficiency or both. ”,是在说明显式指定类型的劣势。
This commit is contained in:
SashaBao 2023-09-20 11:33:38 +08:00 committed by GitHub
parent 1de81e61d5
commit 00cac2e48d
No known key found for this signature in database
GPG Key ID: 4AEE18F83AFDEB23

View File

@ -136,7 +136,7 @@ for(const auto& p : m)
一些开发者也担心使用`auto`就不能瞥一眼源代码便知道对象的类型然而IDE扛起了部分担子也考虑到了[Item4](../1.DeducingTypes/item4.md)中提到的IDE类型显示问题在很多情况下少量显示一个对象的类型对于知道对象的确切类型是有帮助的这通常已经足够了。举个例子要想知道一个对象是容器还是计数器还是智能指针不需要知道它的确切类型。一个适当的变量名称就能告诉我们大量的抽象类型信息。
真正的问题是显式指定类型可以避免一些微妙的错误,以及更具效率和正确性,而且,如果初始化表达式的类型改变,则`auto`推导出的类型也会改变,这意味着使用`auto`可以帮助我们完成一些重构工作。举个例子,如果一个函数返回类型被声明为`int`,但是后来你认为将它声明为`long`会更好,调用它作为初始化表达式的变量会自动改变类型,但是如果你不使用`auto`你就不得不在源代码中挨个找到调用地点然后修改它们。
事实是显式指定类型通常只会引入一些微妙的错误,无论是在正确性还是效率方面。而且,如果初始化表达式的类型改变,则`auto`推导出的类型也会改变,这意味着使用`auto`可以帮助我们完成一些重构工作。举个例子,如果一个函数返回类型被声明为`int`,但是后来你认为将它声明为`long`会更好,调用它作为初始化表达式的变量会自动改变类型,但是如果你不使用`auto`你就不得不在源代码中挨个找到调用地点然后修改它们。
**请记住:**