`auto x = f()` 是否比 `T x = f()` 更好？ [复制]答案

【问题标题】：Is `auto x = f()` better than `T x = f()`? [duplicate]`auto x = f()` 是否比 `T x = f()` 更好？ [复制]
【发布时间】：2013-09-01 00:58:13
【问题描述】：

在另一个主题中有人建议使用

auto x = f();

而不是

T x = f();

（如果f 的签名是T f()）。他们指出，如果有人碰巧将f 更改为U f()，这可以防止静默对象切片，其中U 是T 的后代。

这对我来说很有意义，但我可能还缺少其他的东西。那么，哪个更好，为什么？

【问题讨论】：

【解决方案1】：

在这种情况下使用 auto 的最大优势之一是，正如 Herb Sutter 在 Almost Always Auto 中注意到的那样，auto 使 API 的使用更易于使用。也就是说，无需对客户端代码进行任何必要的更改即可修改/重构 API。
例如：

API v1.0

template<typename T>
T* abstract_factory::create();

template<typename T>
std::shared_ptr<T> abstract_factory::create();

 Foo* instance = abstract_factory::create<Foo>();

 Foo* instance = abstract_factory::create<Foo>(); //TYPE ERROR!!!

 auto instance = abstract_factory::create<Foo>(); //OK! type infered to std::shared_ptr<Foo>

【讨论】：

我是唯一一个认为“无需对客户端代码进行任何必要更改即可修改/重构 API”的人吗？是坏事吗？
如果事情继续需要重新编译，那是因为你从新 API 得到的新东西无论如何都有相同的 duck 类型，因此你不应该需要更改原始代码，除非您的原始代码依赖于特定的实现或类型（在大多数情况下应避免）。在后一种情况下，您应该指定所需的类型（例如auto x = TypeINeed(f());）。 Herb Sutter 发表的文章很好地证明了这一点
对不起，我的意思是“如果事情继续进行而不需要重新编译 [...]”