如何将内联函数放在C＆＃x2B;＆＃x2B;源文件？
我如何强制函数的嵌入，但在C ++文件中定义它？
这是过去问的一个问题，例如：将内联方法从标头文件移动到.cpp文件
简而言之，在那里的答案如下：“ inline用于表示[删除函数呼叫呼叫开销以.TEXTS大小为代价] ，现在这意味着[放松ODR]，所以不要在与ODR无关的任何内容中使用内联，编译器知道更好”。
我意识到这一点，但是在我有些异国情调的情况下，我不在乎表现。
我正在编程嵌入式设备，如果有人突破其他安全性，我想使其尽可能地令人讨厌以反向工程，这是代码的这一部分，这意味着我不想要功能呼叫（无论如何都没有被调用）以揭示功能边界，这些功能界限是自然而然的代码界限，这些代码自然而然地实现了一些目标。
但是，我也想保持我的代码有序，而我的标题文件中没有代码。
我看到我可以使用__属性（（（force_inline）））强制插图，但是如果这些函数没有inline属性，我也会收到警告：警告：ewlance_inline函数可能无法无法安排[-wattributes]
抑制属性警告是一个选项，但是只有一旦我确定没有干净的方法来执行此操作，我才宁愿接受它。
因此，问题：我如何具有强制性的函数，其声明在标题中，但是定义在源文件中，而不会抑制所有属性警告？那是不可能的吗？
How can I force the inlining of a function, but define it in a C++ file ?
This is a question that's been asked in the past, for example here: Moving inline methods from a header file to a .cpp files
The answers there, in short, go as follows: "inline used to mean [remove function call overhead at the expense of .text size], now it means [relax ODR], so don't use inline for anything that's not ODR related, the compiler knows better".
I'm aware of that, however in my somewhat exotic case, I don't care about performance.
I'm programming an embedded device and, should someone break through the other layers of security, I want to make it as obnoxious as possible to reverse engineer this part of the code, and one thing this implies is that I don't want function calls (that aren't called numerous times anyway) to expose the function boundaries, which are natural delimitations of pieces of code that achieve something on their own.
However, I would also like to keep my code orderly and not have code in my header files.
I see that I can use __attribute((force_inline)) to force inlining, but then I get warnings if those functions don't have an inline attribute too: warning: always_inline function might not be inlinable [-Wattributes]
Suppressing the attributes warning is an option, but I'd rather only take it once I'm sure there are no clean way to do this.
Hence the question: how can I have a forcibly inlined function whose declaration is in a header, but definition is in a source file, without suppressing all attributes warnings ? Is that impossible ?
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（1）
插入只能是 。有时有点有力。但是您永远无法保证函数最终会嵌入 - 因为原因，有时是相当晦涩的原因。
这里是MSVC文档所说的内容（我重点介绍了重要部分）：
C ++标准说：
海湾合作委员会文档对不可分割的功能的清晰清晰较低，但无论如何存在。
强迫内线的唯一“真实”方式非常丑陋，因为它依靠在编译之前将其插入...是的，老式的预处理器宏。邪恶本身。或通过使用
#include替换函数调用（并插入C ++代码）... May 比宏观更安全，关于dou率，评估，但是其他副作用可能会更糟，因为它必须依靠“全局”变量来工作。值得痛苦吗？可能不是。特别是“混淆”，因为它不会像您认为的那样“安全”。是的，明确的函数调用更容易追踪。但这不会改变任何事情：反向工程不依赖于此。实际上，混淆是从不一个好的（甚至是工作...）解决方案。我曾经以为……很久以前。我向自己证明了它几乎没有用。我自己的“安全”代码。打破代码比我“保护”它花的时间要少得多...
Inlining can only be asked. Sometimes a bit forcefully. But you can never guarantee that the function WILL be inlined finally - because reasons, sometimes quite obscure ones.
Here what's MSVC documentation says (I've highlighted the important parts):
C++ standard says:
GCC documentation is a bit less crystal-clear about non-inlinable functions, but cases exists anyway.
The only "real" way to force inlining is quite ugly, since it rely on inlining it before compilation... Yeah, old-style preprocessor macros. The Evil Itself. Or by using a dirty hack with a
#includereplacing the function call (and inserting C++ code instead)... It may be a bit safer than a macro, regarding double evaluations, but other side-effects can be even worse since it must rely on "global" variables to work.Does it worth the pain? Probably not. In particular for "obfuscation", because it won't be as "secure" as you think it will be. Yes, an explicit function call is easier to trace. But it won't change anything: reverse engineering don't rely on that to be done. In fact, obfuscation is near never a good (or even working...) solution. I used to think that... a long, very long time ago. I proved to myself that it was near useless. On my own "secured" code. Breaking the code took me much less time than it took me to "protect" it...