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

When should I use C++14 automatic return type deduction?

本文关键字：返回类型 c++ 什么时候      更新时间：2023-10-16

随着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};代替vector，但这并不总是有效的，我们需要在函数头和函数体中指定类型。这完全是冗余的，而自动返回类型演绎使我们省去了这种冗余。

场景4

最后，它可以用来代替非常简单的函数: 
auto position() {
    return pos_;
}
auto area() {
    return length_ * width_;
}

但是，有时我们可能会查看函数，想知道确切的类型，如果那里没有提供，我们必须转到代码中的其他点，例如声明pos_的地方。

结论

有了这些场景，哪一种情况实际上证明了这个特性在使代码更干净方面是有用的?我在这里没有提到的情况呢?在使用这个功能之前，我应该采取哪些预防措施，以免以后被它咬伤?这个功能带来了什么新的东西，没有它是不可能的?

请注意，多重问题是为了帮助找到回答这个问题的角度。

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

在C和c++ 03中，对这个问题的传统回答是"在语句边界中，我们使类型显式，在表达式中，它们通常是隐式的，但我们可以通过强制类型转换使它们显式"。c++ 11和c++ 1y引入了类型推导工具，以便您可以在新的地方省略类型。

对不起，你不能通过制定一般规则来解决这个问题。你需要查看特定的代码,自己决定是否艾滋病可读性指定类型的:它是更好地为您的代码说,"这是X的类型",还是对你的代码更好说,"这个东西的类型是无关紧要的理解这部分的代码:编译器需要知道我们可能解决它,但我们不需要在这里说"?

因为"可读性"并不是客观定义的[*]，而且它因读者而异，作为一段不能完全被风格指南所满足的代码的作者/编辑，你有责任。即使在某种程度上，风格指南确实规定了规范，不同的人会喜欢不同的规范，并且会倾向于发现任何不熟悉的东西"可读性较差"。因此，一个特定建议的样式规则的可读性通常只能在其他样式规则的上下文中进行判断。

你所有的场景(甚至是第一个)都会发现某人的编码风格有用。就我个人而言，我发现第二种用例是最引人注目的，但即使如此，我预计它将取决于您的文档工具。在文档中看到函数模板的返回类型是auto并不是很有帮助，而在文档中看到它作为decltype(t+u)创建了一个可以(希望)依赖的发布接口。

[*]偶尔有人试图做一些客观的测量。在很小的程度上，有人曾经提出任何统计上重要的和普遍适用的结果，他们完全被工作的程序员忽视，赞成作者的直觉什么是"可读的"。

一般来说，函数返回类型对记录函数有很大帮助。用户将知道期望的是什么。但是，在一种情况下，我认为去掉返回类型以避免冗余可能会更好。下面是一个例子:

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的返回类型相同时，我不确定记录它的返回类型是否有用。我认为，在这种特殊情况下，删除返回类型使函数更具可读性。请注意，在将apply添加到标准N3915的提案中，这个返回类型实际上已经被丢弃并被decltype(auto)所取代(还请注意，我的原始答案早于本文):

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 << "foon"; }
};
struct Y
{
    void bar() const { std::cout << "barn"; }
};
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将触发编译时错误。

这是没有必要的。至于什么时候应该——你会得到很多不同的答案。我想说，在它成为标准的一部分并得到大多数主要编译器以同样的方式的良好支持之前，根本不会。

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

这与函数的简单性无关(正如现在已删除的该问题的副本所假定的那样)。

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

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

假设您想为后续的长函数调用创建一个短别名。有了auto，你不需要关心原来的返回类型(也许将来会改变)，用户可以点击原来的函数来获得真正的返回类型:

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

PS:这取决于这个问题。

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

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

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

虽然还有其他方法可以处理，但使用auto返回类型似乎是一个很好的选择。

对于场景3，我会将函数签名的返回类型与要返回的局部变量转换。这将使客户端程序员更清楚地了解函数返回的内容。这样的:

场景3 防止冗余:

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

是的，它没有auto关键字，但原则是一样的，以防止冗余，并为无法访问源代码的程序员提供更轻松的时间

相关文章：