问题标签 [return-type-deduction]

Programming languages with some variant of Hindley-Milner type inference can easily infer the type of expressions such as

whereas the return type inference in C++1y fails for the following :

I tried this with clang 3.5 and the command

and I get

What is lacking in C++'s return type inference that disallows using variable in it's own initializer when return type has to be inferred? What can I do to work around this problem, and better still, what can we do to fix this in the language?

我正在尝试推断函数的返回类型并将其用作成员函数的返回类型。为此，我使用了 decltype 表达式。但是，如果给定的函数将引用作为参数，我所有的尝试都无法编译：

• 我不能在 decltype 表达式中使用我的类的任何成员变量，因为编译器抱怨没有这样的成员（见func1下文）
• 我不能对函数参数使用临时值，因为函数需要一个引用，并且您不能将非常量左值引用绑定到临时值（见func2下文）

我还尝试了各种强制转换运算符来使引用成为临时的，但似乎没有什么是有效的表达式。

这是一个代码示例：

在 c++14decltype(auto)中引入了这个成语。

通常它的用途是允许auto声明使用decltype给定表达式的规则。

搜索成语“良好”用法的示例，我只能想到以下内容（由Scott Meyers 撰写），即函数的返回类型推导：

是否有任何其他示例表明此新语言功能很有用？

g++ 似乎接受auto和decltype(auto)作为初始和尾随返回类型的任何组合：

但是，clang 拒绝jandk说：错误：具有尾随返回类型的函数必须指定返回类型“auto”，而不是“decltype(auto)”（演示）。

哪个编译器是正确的？在每种情况下应使用哪个规则（auto或）？在trailing-return-typedecltype(auto)中使用占位符类型是否有意义？

如何简化此代码？我想写代码作为评论中的代码。C++11 result_of 和 decltype 似乎有帮助，但我不够聪明，无法编写正确的代码来推断类内函数 f 的输入和输出类型。你能帮我看到光吗？谢谢

当我跳过表达式的返回类型时

C++11中的以下代码：

等于C++14中的以下代码：

但另外可以在C++14decltype中推导出没有规则的返回类型：

当我知道返回类型到底是什么时

C++11中的以下代码：

等于C++03中的以下代码：

一个不应该发生的奇怪例子

C++11中的以下代码：

等于C++14中的以下代码：

请纠正我，如果上面的代码是错误的并且不能按预期工作。

编辑，根据评论（Yakk）：它们并不真正相等，第一个（C++11示例）是隐式转换，而第二个（static_castC ++14示例）是显式转换。

结论

如您所见，我可以在不使用C++11的替代函数语法特性的情况下完成所有操作。我对么？我可以完全忘记它而不会遇到任何技术问题吗？

一般来说，可以避免以下语法：

赞成以下语法：

我是否忘记了 C++11 的尾随返回类型特性的任何使用，而 C++14 的函数返回类型推导特性是不可能的？

我正在将我的部分代码库从 C++11 升级到 C++14。我有几个数学实用函数，它们接受多个输入参数并返回一个 type 值std::common_type_t<...>。

我正在考虑用简单的auto. 我认为类型推导确实试图在这些情况下找到一个共同的类型。有没有这样行不通的情况？

用 转换所有出现的返回值总是安全的吗？std::common_type_T<...>auto

示例函数：

以下程序会产生编译错误clang，尽管它会传递给其他编译器：

clang产量：

该程序是否非法，如果是，是否有正确的定义方法foo::bar_type？

clang细节：

由于decltype作为返回类型，C++11 使得引入装饰器变得非常容易。例如，考虑这个类：

我想用额外的功能来装饰它，因为我会用不同种类的装饰做几次，我首先介绍一个decorator简单地将所有内容转发到base. 在实际代码中，这是通过std::shared_ptr这样来完成的，这样我就可以删除装饰并恢复“裸”对象，并且所有内容都是模板化的。

完美的转发，decltype真是太棒了。在实际代码中，我实际上使用了一个只需要函数名称的宏，其余的都是样板文件。

然后，我可以引入一个derived为我的对象添加特性的类（这derived是不恰当的，同意，但它有助于理解derivedis-a-kind of base，尽管不是通过继承）。

然后 C++14 来了，带有返回类型推导，它允许以更简单的方式编写东西：删除decltype转发函数的部分：

然后它就坏了。是的，至少根据 GCC 和 Clang，这是：

不等于这个（问题不是autovs. decltype(auto)）：

重载决议似乎完全不同，它的结尾是这样的：

我理解失败：我的调用 ( d.fun(foo_t{})) 与 的签名不完全匹配derived::fun，它需要 a const foo_t&，所以非常急切地decorator::fun开始了（我们知道如何Args&&...非常不耐烦地绑定到任何不完全匹配的东西）。所以它将这个转发给base::fun无法处理的foo_t。

如果我derived::fun改为采用 afoo_t而不是const foo_t&，那么它按预期工作，这表明确实这里的问题是derived::fun和之间存在竞争decorator::fun。

但是，为什么这会显示返回类型的扣除？？？更确切地说，为什么委员会会选择这种行为？

为了让事情变得更容易，在 Coliru 上：

• decltype有效的版本
• 类型推导失败的版本

谢谢！

我很难理解如何实现N3638auto中描述的类型说明符的 C++14 扩展，以及究竟允许什么。

具体来说，该标准的一项更改说，

如果函数声明的返回类型包含占位符类型，则函数的返回类型是从函数体中的返回语句推导出来的，如果有的话。

当函数体与声明在同一个文件中时，很容易看出这是如何工作的；但考虑头文件使用auto占位符声明方法但未定义它的情况。包含此头文件但不包含定义方法的文件的翻译单元如何编译成功？

例如，给定文件foo.hpp：

...和文件foo.cpp：

...和文件main.cpp：

main.cpp...自行编译是否合法？如果不是，为什么不呢？如果是这样，如何get_x实例化，因为编译器无法知道gen_dataeven 的返回类型是否有一个名为 的成员x，更不用说它的偏移量是多少了？

不过，即使不担心模板实例化，这似乎也是个问题；例如，如果您尝试f.gen_data().x直接访问或将其传递给函数会发生什么？