161

随着 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_声明的位置。

结论

列出了这些场景，其中哪些实际上被证明是该功能有助于使代码更清晰的情况？我在这里没有提到的场景呢？在使用此功能之前我应该​​采取哪些预防措施，以免它以后咬我？如果没有它，这个功能有什么新东西是不可能的吗？

请注意，多个问题旨在帮助找到回答这个问题的观点。

4

7 回答 7

68

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

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

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

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

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

[*] 偶尔有人会尝试进行一些客观的测量。在任何人曾经提出任何具有统计意义和普遍适用的结果的小范围内，它们被工作的程序员完全忽略，有利于作者对什么是“可读”的直觉。

于 2013-04-01T04:41:58.740 回答
31

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

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是将 a 的元素转发std::tuple给函数并返回结果。int_seq和只是实现的make_int_seq一部分，可能只会让任何试图理解它的用户感到困惑。

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

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();
}

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

于 2013-04-08T14:44:13.943 回答
12

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

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

于 2013-04-01T03:28:59.413 回答
8

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

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

于 2015-06-02T20:35:14.890 回答
4

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

想象一下，您想为后续较长的函数调用创建一个短别名。使用 auto 你不需要关心原始的返回类型（也许将来会改变），用户可以点击原始函数来获取真正的返回类型：

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

PS：取决于这个问题。

于 2018-05-17T23:48:04.467 回答
3

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

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

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

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

于 2015-10-09T15:14:17.183 回答
2

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

场景 3 为防止冗余：

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

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

于 2018-09-14T13:13:01.240 回答