【问题标题】:Specify always_inline for functions by Compiler通过编译器为函数指定 always_inline
【发布时间】:2013-11-08 09:02:13
【问题描述】:

我正在构建一个使用其他 CPP 代码的 RT CPP 程序。
我无法更改重用代码!

我需要强制编译器内联几个方法。

我的问题很明显,我不能在代码中添加always_inline 并感到高兴。

我正在与Windriver WorkBench 3.3 合作,为VxWorks 6.9 工作

注意:我可以随意改变环境。

有什么想法吗?

编辑(解释大局):

  • 图书馆是一个清晰案例项目
  • 代码是很多项目(包括我的项目)使用的库
  • 每个项目使用不同的功能集
  • 在我的项目中,我们经常使用大约 20 个函数并希望内联它们以获得所需的性能

目前,我们“劫持”文件以内联函数,
但这并不好,因为我们错过了从 lib 存储库合并更改的机会。

我认为我们可以使用环境来指定编译器的内联决策,避免“劫持”状态,能够合并库中的更改等。

注意:不同的项目需要内联不同的函数。

【问题讨论】:

  • 为什么他们必须内联?
  • 为什么不能更改重用的代码,为什么必须内联?
  • 代码是许多项目使用的库,我们经常使用几个(20)个函数,并希望它们内联以获得所需的性能。

标签: c++ real-time inline vxworks workbench


【解决方案1】:

与其劫持文件,为什么不对其进行分支,并将内联指令添加到您的版本中?这样,您可以定期根据最新版本重新基线,并合并到最新的库中。

或者,将更改提取为补丁,并将补丁作为构建过程的一部分应用。这样至少您不必手动编辑它。

或者,使 always_inline 有条件,以便您可以在编译时打开它。这样,其他用户不会受到影响,这应该允许您在他们所属的库中进行更改

我不知道开发环境中有任何选项可以强制它,尽管您可能想要调整 -finline-limit,并可能关闭 optimise-for-space。

但是您确认函数调用的开销确实有影响吗?

【讨论】:

  • 嗨,感谢您的详细回复。 always_inline 可将本项目所需的性能提高 4-5%。制作有条件的 always_inline 标志是有问题的,因为有许多项目具有不同的内联偏好。补丁,是合理的..我会考虑的。
  • 我想您可以将函数分组到通常内联在一起的区域中,并具有一组条件,但我明白这一点,它确实变得更难管理。我会去分支库,而不是补丁,但任何一个都应该工作。
猜你喜欢
  • 2012-10-13
  • 1970-01-01
  • 2021-11-02
  • 2012-11-04
  • 1970-01-01
  • 1970-01-01
  • 2020-04-15
  • 2019-08-26
  • 1970-01-01
相关资源
最近更新 更多