新关键字“auto”；什么时候应该使用它来声明变量类型？

Question

可能的重复：
C++0x auto 关键字多少就太多了

我们（作为一个社区）是否有足够的经验来确定汽车何时和/或是否被滥用？

我真正想要的是关于

• 何时使用 auto
• 何时应避免的

最佳实践指南简单的经验法则可以在 80% 的情况下快速遵循。

作为上下文，这个问题是由我的回答引发的

Answer 1

我认为当该类型在项目中工作（或将要工作）的共同程序员中非常知名时，可以使用 auto ，例如在以下代码中：

//good : auto increases readability here
for(auto it = v.begin(); it != v.end(); ++it) //v is some [std] container
{
      //..
}

或者，更一般地说，

//good : auto increases readability here
for(auto it = std::begin(v); it != std::end(v); ++it)//v could be array as well
{
      //..
}

---

但是当类型不是很知名并且不经常使用时，那么我认为 auto 似乎会降低可读性，例如这里：

//bad : auto decreases readability here
auto obj = ProcessData(someVariables);

而在前一种情况下，使用 auto code> 看起来很好并且不会降低可读性，因此，可以广泛使用，但在后一种情况下，它会降低可读性，因此不应使用。

---

另一个可以使用 auto 的地方是当您使用 new¹ 或 make_* 函数时，例如这里：

//without auto. Not that good, looks cumbersome
SomeType<OtherType>::SomeOtherType * obj1 = new SomeType<OtherType>::SomeOtherType();
std::shared_ptr<XyzType> obj2 = std::make_shared<XyzType>(args...);
std::unique_ptr<XyzType> obj2 = std::make_unique<XyzType>(args...);

//With auto. good : auto increases readability here
auto obj1 = new SomeType<OtherType>::SomeOtherType();
auto obj2 = std::make_shared<XyzType>(args...);
auto obj3 = std::make_unique<XyzType>(args...);

在这里它非常好，因为它减少了键盘的使用，而不降低可读性，因为任何人都可以通过查看代码来知道正在创建的对象的类型。

<子>1。不过，请避免使用 new 和原始指针。

---

有时，类型是如此无关紧要，甚至不需要类型的知识，例如在表达式模板中；事实上，实际上不可能（正确地）编写类型，在这种情况下，auto对程序员来说是一种解脱。我编写了表达式模板库，可用作：

foam::composition::expression<int> x;

auto s = x * x;       //square
auto c = x * x * x;   //cube
for(int i = 0; i < 5 ; i++ )
    std::cout << s(i) << ", " << c(i) << std::endl; 

输出：

0, 0
1, 1
4, 8
9, 27
16, 64

现在将上面的代码与以下不使用 auto 的等效代码进行比较：

foam::composition::expression<int> x;

//scroll horizontally to see the complete type!!
foam::composition::expression<foam::composition::details::binary_expression<foam::composition::expression<int>, foam::composition::expression<int>, foam::operators::multiply>> s = x * x; //square
foam::composition::expression<foam::composition::details::binary_expression<foam::composition::expression<foam::composition::details::binary_expression<foam::composition::expression<int>, foam::composition::expression<int>, foam::operators::multiply> >, foam::composition::expression<int>, foam::operators::multiply>> c = x * x * x; //cube

for(int i = 0; i < 5 ; i++ )
    std::cout << s(i) << ", " << c(i) << std::endl; 

如您所见，在这种情况下，auto 会让您的生活变得更加轻松。上面使用的表达方式非常简单；想想一些更复杂的表达式的类型：

auto a = x * x - 4 * x + 4; 
auto b = x * (x + 10) / ( x * x+ 12 );
auto c = (x ^ 4 + x ^ 3 + x ^ 2 + x + 100 ) / ( x ^ 2 + 10 );

这样的表达式的类型会更加庞大和丑陋，但是感谢 auto，我们现在可以让编译器推断表达式的类型。

---

因此，底线是：关键字 auto 可能会提高或降低代码的清晰度和可读性，取决于上下文。如果上下文清楚地表明它是什么类型，或者至少应该如何使用它（在标准容器迭代器的情况下），或者甚至不需要实际类型的知识（例如在表达式中） templates），那么应该使用auto，如果上下文没有说清楚并且不是很常见（比如上面的第二种情况），那么它最好避免。

Answer 2

简单的。当您不关心类型是什么时使用它。例如，

for (auto i : some_container) {
   ...

我在这里关心的是 i 是容器中的任何内容。

这有点像 typedef。

typedef float Height;
typedef double Weight;
//....
Height h;
Weight w;

在这里，我不关心 h 和 w 是浮点数还是双精度数，只关心它们是适合表达身高和体重的类型 。

或者考虑

for (auto i = some_container .begin (); ...

这里我所关心的是它是一个合适的迭代器，支持operator++()，在这方面它有点像鸭子类型。

而且 lambda 的类型无法拼写，因此 auto f = []... 是很好的风格。另一种方法是转换为 std::function ，但这会带来开销。

我真的无法想象对 auto 的“滥用”。我能想到的最接近的方法是剥夺自己对某种重要类型的显式转换——但您不会为此使用 auto ，而是构造一个所需类型的对象。

如果您可以删除代码中的一些冗余而不引入副作用，那么这样做一定是件好事。

Answer 3

我会应用与 C# 中的 var 相同的规则：自由地使用它。它增加可读性。除非变量的类型实际上很重要，需要明确说明，在这种情况下应该这样做（废话）。

尽管如此，我仍然认为（特别是在静态类型语言中）编译器在为我们跟踪类型方面比我们更好。大多数时候，精确类型无论如何都不是非常重要（否则接口在实践中将无法工作）。更重要的是要了解哪些操作是允许的。上下文应该告诉我们这一点。

此外，auto 实际上可以通过防止初始化中不需要的隐式转换来防止错误。通常，如果 y 不是 Foo 类型并且存在隐式转换，则语句 Foo x = y; 将执行隐式转换。这就是首先要避免隐式转换的原因。不幸的是，C++ 已经有太多这样的东西了。

编写auto x = y;原则上可以避免这个问题。

另一方面，应该清楚的是，当我执行假设整数中的这个或那个字节数的计算时，必须知道并且应该清楚地说明变量的显式类型。

并非所有情况都如此明确，但我认为大多数情况都是如此，并且

1. 在大多数情况下很容易看出是否需要知道显式类型，并且
2. 对显式类型的需求相对较少。

Eric Lippert，C# 编译器团队的主要开发人员， 的说法与关于var。

Answer 4

我认为你的第一个问题的答案是否定的。我们知道足够的知识来整理一些关于何时使用或避免 auto 的指南，但它们仍然留下相当多的情况，我们目前能说的最好的办法是我们还不能提供太多帮助关于他们的客观建议。

您几乎必须使用它的明显情况是在模板中，当您想要（例如）正确的类型来保存对两个泛型参数进行某些操作的结果时。在这种情况下，滥用的唯一可能性实际上并不是滥用 auto 本身，而是您正在执行的一般操作类型（或您正在编写的模板类型等） .) 是你最好避免的事情。

至少在某些情况下，您显然需要避免 auto。如果您使用类似代理类型的东西，其中您依赖于 proxy->target 的转换来完成手头的部分工作，auto 将（尝试）创建一个目标与源的类型相同，因此不会发生转换。在某些情况下，这可能只是延迟转换，但在其他情况下，它根本不起作用（例如，如果代理类型不支持分配，这通常是这种情况）。

另一个例子是，当您需要确保特定变量具有特定类型（例如外部接口）时。例如，考虑将网络掩码应用于 IP (v4) 地址。为了便于讨论，我们假设您正在使用地址的各个八位字节（例如，将每个八位字节表示为 unsigned char），因此我们最终得到类似 octets[0 ] &掩码[0]。由于 C 的类型提升规则，即使两个操作数都是 unsigned char，结果通常也是 int。我们需要结果是一个unsigned char（即一个八位字节），而不是一个int（通常是4个八位字节）。因此，在这种情况下，auto 几乎肯定是不合适的。

尽管如此，在很多情况下仍然需要做出判断。对于这些情况，我自己的倾向是将 auto 视为默认值，并且仅在至少有点像我引用的后一种情况的情况下使用显式类型上面 - 即使正确操作不需要特定类型，但我确实想要特定类型，即使这可能涉及隐式转换。

我的猜测（但这只是猜测）是，随着时间的推移，我可能会更加倾向于这个方向。随着我越来越习惯编译器挑选类型，我会发现在相当多的情况下，我目前认为应该指定类型，但我确实不需要，并且代码会没事吧。

我怀疑我们中的很多人（年龄越大/经验越丰富，可能会变得越糟糕）会使用显式类型，其原因最终可以追溯到对性能的一些感觉，并相信我们的选择会提高性能。有时我们可能甚至是对的——但正如我们大多数拥有丰富经验的人所发现的那样，我们的猜测常常是错误的（特别是当它们基于隐式假设时），并且编译器和随着时间的推移，处理器通常也会在这些事情上变得更好。

Answer 5

我使用过具有完整类型推断的语言。我认为没有理由不在技术上可行的地方放置 auto*。事实上，我可能已经编写了 auto i = 0;，其中 int 比 auto 短了一个字符。我什至不确定我是否这样做，因为最根本的是：我不关心清单类型。

*：例如 auto int[] = { 0, 1, 2, 3 } 不起作用。

Answer 6

仅将其与长重复类型一起使用，例如长模板和 lambda 函数类型。如果可以的话尽量避免它，让事情变得清楚。