“隐藏内联方法” XCode4 中的选项。

发布于 2024-12-19 15:35:43 字数 341 浏览 0 评论 0原文

查看文档信息: 隐藏内联方法 GCC_INLINES_ARE_PRIVATE_EXTERN = 是 启用后,内联方法的外联副本被声明为“private extern”。[GCC_INLINES_ARE_PRIVATE_EXTERN, -fvisibility-inlines-hidden

有谁知道它将如何影响 C++ 库?我的iphone项目基于C++库,使用google protobuf,我发现一些奇怪的问题,库内联函数不会被“内联方法隐藏”选项设置为YES而触发,实际上它是系统默认值,设置为NO它可以工作嗯,我不知道为什么?里面到底有什么秘密呢?

欢迎对此话题感兴趣的朋友分享和讨论,先谢过。

See document information:
inline Methods Hidden
GCC_INLINES_ARE_PRIVATE_EXTERN = YES
When enabled, out-of-line copies of inline methods are declared 'private extern'.[GCC_INLINES_ARE_PRIVATE_EXTERN, -fvisibility-inlines-hidden

Does anyone know how it will effect undergoing C++ library? My iphone project is based on C++ library, using google protobuf, I find some strange issue that library inline function will not be triggered by "inline Methods Hidden" option set to YES, in fact it is system default value, set to NO it works well, I don't know why? What's the secret inside?

Anyone who are interested in this topic please share and discuss, thanks in advance.

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

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

发布评论

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

评论(1

猛虎独行 2024-12-26 15:35:43

秘密在于单一定义规则。如果内联被隐藏,那么您最终可能会得到每个图像的内联的多个(私有)副本。

理想情况下,您应该配置和使用所有内容,以便它能够使用一个定义规则运行,然后您可以启用私有外部作为一种优化(这可能不是在各个方面都很好,特别是二进制大小)。您会喜欢这种方法,因为它遵循标准的模型。

快速回顾一下 ODR:

// somewhere.hpp
namespace MON {
inline int cas(const int*,const int*,int*) {
    return dah_dum();
}}

// elsewhere.hpp
namespace MON {
inline int cas(const int*,const int*,int*) {
    return dum_dah();
}}

任何不是完全或部分内联的 int MON::cas(const int*,const int*,int*) 引用,而是对 int 的函数调用MON::cas(const int*,const int*,int*) 可能会导致使用任一定义,无论哪个定义对 TU 可见。链接器仅保留一个定义,并且假定所有定义都相同。这很重要,因为如果每个被引用和可见的定义都会为每个翻译生成一个副本,那么您的二进制大小将会爆炸。

如果它在使用 ODR 规则时“有效”,那么您的目标文件中的给定符号可能有多个定义,并且由于编译器设置,您最终会引用不同的定义。如果您声明了非静态或匿名名称空间中的内联,则所有源文件中的定义应该相同。

如果您将其与 C TU 混合,那么......它具有不同的链接规则,这只会​​使问题进一步复杂化。

The secret is the one definition rule. If the inlines are hidden, then you may end up with multiple (private) copies of inlines per image.

Ideally, you'd configure and use everything so that it is able to function using the one definition rule, then you might enable private externs as an optimization (which may not be good in every regard, particularly binary size). You would favor this approach because it follows the standard's model.

For a quick refresher on ODR:

// somewhere.hpp
namespace MON {
inline int cas(const int*,const int*,int*) {
    return dah_dum();
}}

// elsewhere.hpp
namespace MON {
inline int cas(const int*,const int*,int*) {
    return dum_dah();
}}

Any int MON::cas(const int*,const int*,int*) reference which is not wholly or partially inlined, but a function call to int MON::cas(const int*,const int*,int*) may result in use of either definition regardless of which definition was visible to the TU. Exactly one definition is preserved by the linker, and all definitions are assumed to all be equal. That's important because your binary sizes would explode if every definition which is referenced and visible would yield a copy for each translation.

If it 'works' when using rules of ODR, then it's likely that you have multiple definitions of a given symbol in your object files, and that you are end up referencing different definitions due to the compiler setting. If you have declared an inline which is not static or in an anonymous namespace, the definition should be the same across all source files.

If you're mixing this with C TUs, well... it has different rules for linkage which only complicates the matter further.

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