我应该何时使用C ++ 14自动返回类型演绎？
随着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_声明的地方。
结论
有了这些场景，其中哪些实际上证明了这种特性有助于使代码更清洁？我忽略了在这里提到的场景呢？在使用此功能之前应该采取哪些预防措施，以便稍后不再咬我？这个功能带来了什么新功能，如果没有它，这是不可能的？
请注意，多个问题旨在帮助你找到解决问题的观点。
Stack Overflow用户
发布于 2018-03-20 09:02:45
C ++ 11引发了类似的问题：什么时候在lambda表达式中使用返回类型推导，以及何时使用auto变量。
对C和C ++ 03中的问题的传统回答是“跨语句边界，我们使类型显式化，在表达式中它们通常是隐含的，但我们可以通过强制转换来明确它们”。C ++ 11和C ++ 1y引入了类型推导工具，以便您可以将类型排除在新的位置。
对不起，但你不打算通过制定一般规则来解决这个问题。你需要查看特定的代码，并自行决定它是否有助于可读性来指定遍布各处的类型：你的代码更适合说“这个事物的类型是X”还是更适合你的代码要说：“这个东西的类型与理解这部分代码无关：编译器需要知道，我们可以解决这个问题，但我们不需要在这里说出来”？
由于“可读性”没有客观定义[*]，而且读者也会有所不同，所以您有责任作为风格指南无法完全满足的一段代码的作者/编辑。即使风格指南确实规定了规范，但不同的人会更喜欢不同的规范，并且会倾向于发现任何不熟悉的内容，使其“不易读”。所以，特定的风格规则的可读性通常只能在其他风格规则的背景下进行判断。
所有的场景（甚至是第一个场景）都可以用于某种人的编码风格。就我个人而言，我发现第二个是最引人注目的用例，但即使如此，我预计它将取决于您的文档工具。查看记录函数模板的返回类型并不是很有帮助auto，而将它记录为decltype(t+u)创建一个已发布的接口，你可以（希望）依赖它。
https://stackoverflow.com/questions/-100007683
复制相似问题