lambda 到函数指针转换的稳定性和唯一性

发布于 2025-01-10 06:16:22 字数 284 浏览 2 评论 0原文

无捕获 lambda 可以转换为具有与 lambda 表达式相同的参数列表的函数指针。

我想知道这种转换是否保证稳定,即给定一个无捕获的 lambda 表达式,标准是否保证其类型的任何对象的函数指针转换将始终产生相同的指针值?

此外,能否保证该指针值在 lambda 表达式和其他函数中是唯一的?

auto x = []{};
auto x2 = x;
auto y = []{};
assert(+x == +x2); // ?
assert(+x != +y); // ?

A capture-less lambda can be converted to a function pointer with the same parameter list as the lambda expression.

I am wondering whether this conversion is guaranteed to be stable, i.e. given a capture-less lambda expression, is it guaranteed by the standard that the function pointer conversion of any object of its type will always yield the same pointer value?

Furthermore, is it guaranteed that this pointer value is unique among lambda expressions and other functions?

auto x = []{};
auto x2 = x;
auto y = []{};
assert(+x == +x2); // ?
assert(+x != +y); // ?

如果你对这篇内容有疑问,欢迎到本站社区发帖提问 参与讨论,获取更多帮助,或者扫码二维码加入 Web 技术交流群。

扫码二维码加入Web技术交流群

发布评论

需要 登录 才能够评论, 你可以免费 注册 一个本站的账号。

评论(1

只是一片海 2025-01-17 06:16:22

该措辞似乎表明每种类型都有一个函数,因此 assert(+x == +x2); 至少应该成立:

[expr.prim.lambda.closure]/7 不带 lambda 捕获的非泛型 lambda 表达式 的闭包类型> ...有一个转换函数来指向函数指针...该转换函数返回的值是函数F的地址,调用该函数时,与调用闭包类型的函数具有相同的效果闭包的默认构造实例上的函数调用运算符类型。

这似乎表明有一个函数 F,并且闭包类型的所有实例都应该转换为该函数。


该标准似乎并不要求或禁止不同的闭包类型转换为不同的函数。从表面上看,+x != +y 似乎可以采用任何一种方式。

The wording would seem to suggest that there's one function per type, so assert(+x == +x2); at least should hold:

[expr.prim.lambda.closure]/7 The closure type for a non-generic lambda-expression with no lambda-capture ... has a conversion function to pointer to function... The value returned by this conversion function is the address of a function F that, when invoked, has the same effect as invoking the closure type's function call operator on a default-constructed instance of the closure type.

This appears to say that there's a single function F, and that all instances of the closure type should convert to that function.


The standard doesn't seem to require or prohibit that distinct closure types convert to distinct functions. On the surface, it appears that +x != +y could go either way.

~没有更多了~
我们使用 Cookies 和其他技术来定制您的体验包括您的登录状态等。通过阅读我们的 隐私政策 了解更多相关信息。 单击 接受 或继续使用网站,即表示您同意使用 Cookies 和您的相关数据。
原文