背景
作为一种组织策略,我喜欢在复杂的函数中定义局部函数的lambda。这对于封装多步逻辑,重复操作等(通常对功能有益的事情)很有用,但不会在使用范围之外创建可见的东西。它是John Carmack在他的essay on the merits of inlining code中布置的样式的一种/替代的样式,因为它将所有内容整齐地装在要使用的功能中,同时还给了(编译器可识别的)名称记录每个功能块。一个简单的,人为的示例可能看起来像这样(只是假装实际上确实存在某种足以使用这种样式进行操作的东西):
void printSomeNumbers(void)
{
const auto printNumber = [](auto number) {
std::cout << number << std::endl; // Non-trivial logic (maybe formatting) would go here
};
printNumber(1);
printNumber(2.0);
}
从名义上讲,此函数的编译形式被“假定”为创建一个隐式定义的函子的实例,然后针对所提供的每个输入在该函子上调用operator()()
,因为这意味着在C ++中使用lambda。不过,在优化的版本中,as-if rule释放了编译器以内联某些内容,这意味着 actual 生成的代码可能只是内联lambda的内容而跳过定义/实例化仿函数。过去的讨论here和here等都出现过这种内联的讨论。
问题
在我发现的所有lambda内联问题和答案中,所提供的示例并未使用任何形式的lambda capture,它们还很大程度上与将lambda作为参数传递给某些事物有关(即在std::for_each
调用的上下文中内联lambda)。那么,我的问题是:编译器是否仍可以内联一个捕获值的lambda?(因为我假设各种变量的生存期在很大程度上影响了答案) ,即使编译器通过引用捕获了某些东西(即局部变量),编译器能否合理地内联仅在定义函数内部使用的lambda吗?
我的直觉是应该可以进行内联,因为编译器可以完全看到所有代码和相关变量(包括它们相对于lambda的生存期),但是我不是肯定的,我的汇编阅读技能还不足以使自己获得可靠的答案。
其他示例
以防万一,我要描述的特定用例不太清楚,这是上面lambda的修改版本,它利用了我正在描述的模式(再次,请忽略以下事实:代码是人为的,不必要地过于复杂):
void printSomeNumbers(void)
{
std::ostringstream ss;
const auto appendNumber = [&ss](auto number) {
ss << number << std::endl; // Pretend this is something non-trivial
};
appendNumber(1);
appendNumber(2.0);
std::cout << ss.str();
}
我希望优化的编译器应具有足够的信息,以完全内联所有lambda用法,并且在此处不生成(或至少不保留)任何函子,即使它正在使用按引用捕获的变量“应该被视为某些自动生成的闭合类型的成员。
答案 0 :(得分:3)
是的
现代编译器使用“静态单分配”(SSA)作为优化过程。
每次分配或修改值时,都会创建一个概念上不同的值。有时,这些概念上不同的值共享同一性(出于指向指针的目的)。
当您获取某物的地址时,身份就是这种东西的阻碍。
简单引用被转换为它们所引用的值的别名;他们没有身份。这是原始设计参考的意图的一部分,也是为什么您不能拥有指向参考的指针的原因。
具体:
std::string printSomeNumbers(void)
{
std::ostringstream ss;
const auto appendNumber = [&ss](auto number) {
ss << number << "\n"; // Pretend this is something non-trivial
};
printf("hello\n");
appendNumber(1);
printf("world\n");
appendNumber(2.0);
printf("today\n");
return ss.str();
}
编译为:
printSomeNumbers[abi:cxx11](): # @printSomeNumbers[abi:cxx11]()
push r14
push rbx
sub rsp, 376
mov r14, rdi
mov rbx, rsp
mov rdi, rbx
mov esi, 16
call std::__cxx11::basic_ostringstream<char, std::char_traits<char>, std::allocator<char> >::basic_ostringstream(std::_Ios_Openmode)
mov edi, offset .Lstr
call puts
mov rdi, rbx
mov esi, 1
call std::basic_ostream<char, std::char_traits<char> >::operator<<(int)
mov esi, offset .L.str.3
mov edx, 1
mov rdi, rax
call std::basic_ostream<char, std::char_traits<char> >& std::__ostream_insert<char, std::char_traits<char> >(std::basic_ostream<char, std::char_traits<char> >&, char const*, long)
mov edi, offset .Lstr.8
call puts
mov rdi, rsp
movsd xmm0, qword ptr [rip + .LCPI0_0] # xmm0 = mem[0],zero
call std::basic_ostream<char, std::char_traits<char> >& std::basic_ostream<char, std::char_traits<char> >::_M_insert<double>(double)
mov esi, offset .L.str.3
mov edx, 1
mov rdi, rax
call std::basic_ostream<char, std::char_traits<char> >& std::__ostream_insert<char, std::char_traits<char> >(std::basic_ostream<char, std::char_traits<char> >&, char const*, long)
mov edi, offset .Lstr.9
call puts
lea rsi, [rsp + 8]
mov rdi, r14
call std::__cxx11::basic_stringbuf<char, std::char_traits<char>, std::allocator<char> >::str() const
mov rax, qword ptr [rip + VTT for std::__cxx11::basic_ostringstream<char, std::char_traits<char>, std::allocator<char> >]
mov qword ptr [rsp], rax
mov rcx, qword ptr [rip + VTT for std::__cxx11::basic_ostringstream<char, std::char_traits<char>, std::allocator<char> >+24]
mov rax, qword ptr [rax - 24]
mov qword ptr [rsp + rax], rcx
mov qword ptr [rsp + 8], offset vtable for std::__cxx11::basic_stringbuf<char, std::char_traits<char>, std::allocator<char> >+16
mov rdi, qword ptr [rsp + 80]
lea rax, [rsp + 96]
cmp rdi, rax
je .LBB0_7
call operator delete(void*)
.LBB0_7:
mov qword ptr [rsp + 8], offset vtable for std::basic_streambuf<char, std::char_traits<char> >+16
lea rdi, [rsp + 64]
call std::locale::~locale() [complete object destructor]
lea rdi, [rsp + 112]
call std::ios_base::~ios_base() [base object destructor]
mov rax, r14
add rsp, 376
pop rbx
pop r14
ret
请注意,在两个printf调用之间(在程序集中,它们为puts
),除了直接调用operator<<
中的ostringstream
外,没有其他调用。