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提出了类似的问题：何时在lambdas中使用返回类型推导，以及何时使用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（另请注意我的原始答案早于本文）：< / p>

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)允许使用expression SFINAE，但decltype(auto)却没有（即使there is a proposal更改此行为）。例如，foobar函数将调用类型的foo成员函数（如果存在）或调用类型的bar成员函数（如果存在），并假设类始终具有精确foo成员函数bar 1}}或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(); }但两者都不能同时出现：

foobar

在X的实例上调用foo会显示foobar，而在Y的实例上调用bar会显示decltype(auto)。如果您使用自动返回类型扣除（有或没有foobar），您将无法获得表达式SFINAE并在X或Y的实例上调用{{1}}将触发编译时错误。

Answer 3

永远不必要。至于你什么时候应该 - 你会得到很多不同的答案。我不会说它根本不是标准的接受部分，并且以同样的方式得到了大多数主要编译器的良好支持。

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

Answer 4

这与函数的简单性无关（假设这个问题的now-deleted duplicate）。

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

Answer 5

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

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

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

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

Answer 6

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

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

log n / log4

PS：取决于this问题。

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

场景1

场景2

场景3

场景4

结论

6 个答案: