3
可能的例子:是否可以设置一个函数在发布版本时只内联?
#[inline(release)]
fn foo() {
println!("moo");
}
如果没有,是否有可能只包括基于构建类型或其他属性的属性?
可能的例子:是否可以设置一个函数在发布版本时只内联?
#[inline(release)]
fn foo() {
println!("moo");
}
如果没有,是否有可能只包括基于构建类型或其他属性的属性?
[...]是否有可能只包含基于构建类型[...]的属性?
是的。这就是cfg_attr
用于:
#[cfg_attr(not(debug_assertions), inline(always))]
#[cfg_attr(debug_assertions, inline(never))]
fn foo() {
println!("moo")
}
这可能是最接近你的目标。请注意,内联注释(即使是“always”和“never”)可以被编译器忽略。这有很好的理由,你可以在下面阅读。
然而:你想要什么来实现呢?
人类在内联决策上相当糟糕,而编译器非常聪明。即使没有#[inline]
,编译器也会在释放模式下内联函数,只要这样做是个好主意。并且它不会在调试模式下被内联。
如果你没有一个非常好的和特殊的理由来修饰自己的内联,你不应该碰它!编译器会做正确的事在几乎所有情况下:)
即使the reference说:
编译器自动内联基于内部启发式的功能。错误地内联函数实际上可能会使程序变慢,因此应该小心使用它。
我开始看一个项目的代码,崩溃发生在一个内联函数中。即使在调试构建过程中,该函数也是内联的(除非我构建错了)我知道我可以删除该行来解决这个问题,但我认为可能会方便地知道它是否可以有条件地应用。 – NeuralSandwich
嗯,当我使用'#[cfg_attr(not(debug_assertions),inline)]' – NeuralSandwich
@NeuralSandwich时,我仍然在lldb中获得多个位置我更改了我的代码并添加了一些解释。基本上,你永远无法确定。引用说:“'#[inline(never)]'**要求编译器不要执行内联扩展”。 –