按照这个答案我现在想知道规则是什么lambdas 的生命周期以及它与自动转换创建的函数指针的生命周期的关系.关于 lambdas 的生命周期有几个问题(例如 此处和此处),在这种情况下答案是它们的行为与您自己编写的完整函子对象完全一样",但是两者都没有解决转换为函数指针的问题,这可能是一种非常明智的特例.
Following this answer I'm now wondering what the rules are for the lifetime of lambdas and how the relate to the lifetime of function pointers which are created by automatic conversion. There are several questions about the lifetime of lambdas (e.g. here and here), in which case the answers are "they behave exactly like you wrote the full functor object yourself", however neither address the conversion to function pointer which could quite sensibly be a special case.
我整理了这个小例子来说明我的担忧:
I put together this small working example that illustrates my concern:
#include <iostream>
typedef int (*func_t)(int);
// first case
func_t retFun1() {
static auto lambda = [](int) { return 1; };
// automatically converted to func_t
return lambda;
}
// second case
func_t retFun2() {
// no static
auto lambda = [](int) { return 2; };
// automatically converted to func_t and
// the local variable lambda reaches the end of its life
return lambda;
}
int main() {
const int a = retFun1()(0);
const int b = retFun2()(0);
std::cout << a << "," << b << std::endl;
return 0;
}
这两种情况是否都有明确定义?还是仅用于 retFun1()
?问题是:函数指针指向的函数是否需要调用函子对象本身,或者在单独的函数中重新实现主体?"任何一个都有意义,但转换为函数指针特别需要一个无捕获的 lambda 的事实表明它实际上可能是后者.
Is this well defined for both cases? Or only for retFun1()
? The question is: "is the function that the function pointer points required to be calling the functor object itself, or reimplementing the body in a separate function?" Either one would make sense, but the fact that the conversion to function pointer specifically requires a capture-less lambda suggests that it may actually be the latter.
换一种方式 - 我可以看到编译器可能想要实现此类 lambda 表达式的至少两种合理方式.一种可能的合法实现可能是编译器合成如下代码:
Put another way - I can see at least two sensible ways a compiler might want to implement such lambdas. One possible, legal implementation might be for a compiler to synthesize code like:
func_t retFun3() {
struct __voodoo_magic_lambda_implementation {
int operator()(int) const {
return 3;
}
static int plainfunction(int) {
return 3;
}
operator func_t() const {
return plainfunction;
}
} lambda;
return lambda;
}
在这种情况下,retFun
的 static
和非 static
变体都可以.但是,如果编译器实现 lambda 也是合法的,例如:
in which case both the static
and non-static
variants of retFun
would be fine. If however it's also legal for a compiler to implement the lambda like:
static int __voodoo_impl_function(int x);
static struct __voodoo_maigc_impl2 {
int operator()(int) const {
return 4;
}
operator func_t() const {
return __voodoo_impl_function;
}
} *__magic_functor_ptr;
static int __voodoo_impl_function(int x) {
return (*__magic_functor_ptr)(x);
}
func_t retFun4() {
__voodoo_maigc_impl2 lambda;
// non-static, local lifetime
__magic_functor_ptr = λ //Or do the equivalent of this in the ctor
return lambda;
}
那么 retFun2()
是未定义的行为.
then retFun2()
is undefined behaviour.
§5.1.2/6 说:
§5.1.2/6 says:
没有 lambda 捕获的 lambda 表达式的闭包类型有一个公共非虚拟非显式 const 转换函数,指向与闭包类型的函数调用运算符具有相同参数和返回类型的函数的指针.这个转换函数返回的值应该是一个函数的地址,这个函数在调用时与调用闭包类型的函数调用运算符具有相同的效果.
The closure type for a lambda-expression with no lambda-capture has a public non-virtual non-explicit const conversion function to pointer to function having the same parameter and return types as the closure type’s function call operator. The value returned by this conversion function shall be the address of a function that, when invoked, has the same effect as invoking the closure type’s function call operator.
强调我的.
换句话说:因为它是一个函数的地址,而且函数没有生命周期,所以你可以随时调用该函数.您拥有的一切都是明确定义的.
In other words: because it's an address of a function, and functions have no lifetime, you are free to call that function whenever you'd like. Everything you have is well-defined.
有点像你已经完成了:
func_t retFun2()
{
int __lambda0(int)
{
return 2;
}
struct
{
int operator(int __arg0) const
{
return __lambda0(__arg0);
}
operator decltype(__lambda0)() const
{
return __lambda0;
}
} lambda;
return lambda; // just the address of a regular ol' function
}
这篇关于与函数指针转换相关的 lambda 对象的生命周期的文章就介绍到这了,希望我们推荐的答案对大家有所帮助,也希望大家多多支持跟版网!