我什么时候应该使用C ++ 14自动返回类型扣除？

Question

随着GCC 4.8.0的发布，我们有一个支持自动返回类型推导的编译器，这是C ++ 14的一部分。 使用-std=c++1y ，我可以这样做：

auto foo() { //deduced to be int
    return 5;
}

我的问题是：我应该何时使用此功能？ 什么时候需要，何时使代码更清洁？

场景1

我能想到的第一个场景是可能的。 每个可以用这种方式编写的函数都应该是。 这个问题是它可能并不总是使代码更具可读性。

情景2

下一个场景是避免更复杂的返回类型。 作为一个很轻的例子：

template<typename T, typename U>
auto add(T t, U u) { //almost deduced as decltype(t + u): decltype(auto) would
    return t + u;
}

我不相信这确实会成为一个问题，虽然我认为在某些情况下明确依赖于参数的返回类型可能更清楚。

场景3

接下来，为了防止冗余：

auto foo() {
    std::vector<std::map<std::pair<int, double>, int>> ret;
    //fill ret in with stuff
    return ret;
}

在C ++ 11中，我们有时可以return {5, 6, 7}; 代替向量，但这并不总是有效，我们需要在函数头和函数体中指定类型。 这纯粹是多余的，自动返回类型扣除使我们免于冗余。

场景4

最后，它可以用来代替非常简单的功能：

auto position() {
    return pos_;
}

auto area() {
    return length_ * width_;
}

但有时候，我们可能会查看函数，想知道确切的类型，如果没有提供，我们必须转到代码中的另一个点，比如声明pos_地方。

结论

在这些场景中，哪些场景实际上证明了这一特性对于使代码更清晰有用？ 我在这里忽略的情景怎么样？ 在使用此功能之前我应该​​采取什么预防措施，以便以后不会咬我？ 这个功能有什么新东西可以带到桌子上，没有它是不可能的吗？

_{请注意，多个问题旨在帮助您找到解决此问题的观点。}

Answer 1

C ++ 11提出了类似的问题：何时在lambda中使用返回类型推导，以及何时使用auto变量。

C和C ++ 03中问题的传统答案是“跨越语句边界，我们使类型显式化，在表达式中它们通常是隐式的，但我们可以使用强制转换使它们显式化”。 C ++ 11和C ++ 1y引入了类型推导工具，这样你就可以在新的地方省略类型。

对不起，但你不打算通过制定一般规则来解决这个问题。 你需要查看特定的代码，并自己决定它是否有助于在整个地方指定类型的可读性：你的代码更好地说“这个东西的类型是X”，还是更好的你的代码说，“这个东西的类型与理解这部分代码无关：编译器需要知道，我们可能会解决它，但我们不需要在这里说出来”？

由于“可读性”不是客观定义的[*]，而且它因读者而异，因此您有责任作为一段代码的作者/编辑，而风格指南无法完全满足。 即使风格指南确实指定了规范，不同的人也会喜欢不同的规范，并且往往会发现任何不熟悉的“不太可读”。 因此，特定提议的样式规则的可读性通常只能在其他样式规则的上下文中进行判断。

所有场景（甚至第一个场景）都可以用于某人的编码风格。 我个人认为第二个是最引人注目的用例，但即便如此，我预计它将取决于您的文档工具。 查看记录的函数模板的返回类型是auto是不是很有帮助，而将其记录为decltype(t+u)会创建一个可以（希望）依赖的已发布接口。

[*]偶尔会有人尝试做一些客观测量。 在很小的程度上，任何人都想出任何具有统计意义和普遍适用的结果，他们完全被工作程序员所忽略，赞成作者对“可读”的本能。

Answer 2

一般来说，函数返回类型对记录函数有很大帮助。 用户将知道预期的内容。 但是，有一种情况我认为删除返回类型以避免冗余可能会很好。 这是一个例子：

template<typename F, typename Tuple, int... I>
  auto
  apply_(F&& f, Tuple&& args, int_seq<I...>) ->
  decltype(std::forward<F>(f)(std::get<I>(std::forward<Tuple>(args))...))
  {
    return std::forward<F>(f)(std::get<I>(std::forward<Tuple>(args))...);
  }

template<typename F, typename Tuple,
         typename Indices = make_int_seq<std::tuple_size<Tuple>::value>>
  auto
  apply(F&& f, Tuple&& args) ->
  decltype(apply_(std::forward<F>(f), std::forward<Tuple>(args), Indices()))
  {
    return apply_(std::forward<F>(f), std::forward<Tuple>(args), Indices());
  }

这个例子来自官方委员会文件N3493 。 函数apply的目的是将std::tuple的元素转发给函数并返回结果。 int_seq和make_int_seq只是实现的一部分，可能只会混淆任何试图理解它的功能的用户。

如您所见，返回类型只不过是返回表达式的decltype 。 另外， apply_并不是为了让用户看到，我不确定记录其返回类型的有用性，当它与apply的一个或多或少相同时。 我认为，在这种特殊情况下，删除返回类型会使函数更具可读性。 请注意，这个非常返回的类型实际上已被删除并被提交中的decltype(auto)替换为添加apply标准N3915 （也请注意我的原始答案早于本文）：

template <typename F, typename Tuple, size_t... I>
decltype(auto) apply_impl(F&& f, Tuple&& t, index_sequence<I...>) {
    return forward<F>(f)(get<I>(forward<Tuple>(t))...);
}

template <typename F, typename Tuple>
decltype(auto) apply(F&& f, Tuple&& t) {
    using Indices = make_index_sequence<tuple_size<decay_t<Tuple>>::value>;
    return apply_impl(forward<F>(f), forward<Tuple>(t), Indices{});
}

但是，大多数情况下，最好保留该返回类型。 在我上面描述的特定情况下，返回类型是相当不可读的，并且潜在用户将不会从知道它获得任何东西。 一个包含示例的好文档将更有用。

---

尚未提及的另一件事：当declype(t+u)允许使用表达式SFINAE时 ， decltype(auto)不会（尽管有提议要改变这种行为）。 例如， foobar函数将调用类型的foo成员函数（如果存在）或调用类型的bar成员函数（如果存在），并假设类始终具有精确的foo或bar但两者都不是同时：

struct X
{
    void foo() const { std::cout << "foo\n"; }
};

struct Y
{
    void bar() const { std::cout << "bar\n"; }
};

template<typename C> 
auto foobar(const C& c) -> decltype(c.foo())
{
    return c.foo();
}

template<typename C> 
auto foobar(const C& c) -> decltype(c.bar())
{
    return c.bar();
}

在X的实例上调用foobar将显示foo而在Y的实例上调用foobar将显示bar 。 如果您使用自动返回类型推导（使用或不使用decltype(auto) ），则不会获得表达式SFINAE并且在X或Y的实例上调用foobar将触发编译时错误。

Answer 3

这绝不是必要的。 至于你什么时候应该 - 你会得到很多不同的答案。 直到它实际上是标准的公认部分并且以同样的方式得到大多数主要编译器的良好支持，我才会说完全没有。

除此之外，它将成为一个宗教论点。 我个人说永远不会在实际的返回类型中使代码更清晰，更容易维护（我可以查看函数的签名并知道它返回的内容与实际必须读取的代码），并且它消除了你认为它应该返回一种类型，并且编译器认为另一种类型会导致问题（就像我曾经使用的每种脚本语言一样）。 我认为汽车是一个巨大的错误，它将导致比帮助更多的痛苦。 其他人会说你应该一直使用它，因为它符合他们的编程哲学。 无论如何，这超出了本网站的范围。

Answer 4

它与函数的简单性无关（作为这个问题的现在删除的副本 ）。

返回类型是固定的（不使用auto ），或者以复杂的方式依赖于模板参数（在大多数情况下使用auto ，当有多个返回点时与decltype配对）。

Answer 5

考虑一个真实的生产环境：许多函数和单元测试都依赖于foo()的返回类型。 现在假设返回类型需要因任何原因而改变。

如果返回类型在任何地方都是auto ，并且foo()和相关函数的调用者在获取返回值时使用auto ，则需要进行的更改是最小的。 如果没有，这可能意味着数小时非常繁琐且容易出错的工作。

作为一个真实世界的例子，我被要求将模块从使用原始指针更改为智能指针。 修复单元测试比实际代码更痛苦。

虽然还有其他方法可以处理，但使用auto返回类型似乎非常合适。

Answer 6

我想提供一个返回类型auto是完美的示例：

想象一下，您想为长时间的后续函数调用创建一个短别名。 使用auto，您不需要处理原始返回类型（将来可能会更改），用户可以单击原始函数以获取实际返回类型：

inline auto CreateEntity() { return GetContext()->GetEntityManager()->CreateEntity(); }

PS：取决于这个问题。

Answer 7

对于场景3，我将返回函数签名的返回类型，并返回要返回的局部变量。 这将使客户程序员更清楚地了解函数返回。 像这样：

方案3为防止冗余：

std::vector<std::map<std::pair<int, double>, int>> foo() {
    decltype(foo()) ret;
    return ret;
}

是的，它没有auto关键字，但是主体是相同的，以防止冗余，并给不能访问源的程序员一个更容易的时间。