C++性能、优化编译器、.cpp 中的空函数
我有一个非常基本的类,将其命名为 Basic,用于更大项目中的几乎所有其他文件。在某些情况下,需要有调试输出,但在发布模式下,不应启用此输出并且应为 NOOP。
目前,标头中有一个定义,可根据设置打开或关闭宏。所以当关闭时,这绝对是一个 NOOP。我想知道,如果我有以下代码,编译器(MSVS / gcc)是否能够优化函数调用,以便它再次成为 NOOP。 (通过这样做,开关可以位于 .cpp 中,并且在编译/链接时间方面切换速度会快得多)。
--Header--
void printDebug(const Basic* p);
class Basic {
Basic() {
simpleSetupCode;
// this should be a NOOP in release,
// but constructor could be inlined
printDebug(this);
}
};
--Source--
// PRINT_DEBUG defined somewhere else or here
#if PRINT_DEBUG
void printDebug(const Basic* p) {
// Lengthy debug print
}
#else
void printDebug(const Basic* p) {}
#endif
I've a very basic class, name it Basic, used in nearly all other files in a bigger project. In some cases, there needs to be debug output, but in release mode, this should not be enabled and be a NOOP.
Currently there is a define in the header, which switches a makro on or off, depending on the setting. So this is definetely a NOOP, when switched off. I'm wondering, if I have the following code, if a compiler (MSVS / gcc) is able to optimize out the function call, so that it is again a NOOP. (By doing that, the switch could be in the .cpp and switching will be much faster, compile/link time wise).
--Header--
void printDebug(const Basic* p);
class Basic {
Basic() {
simpleSetupCode;
// this should be a NOOP in release,
// but constructor could be inlined
printDebug(this);
}
};
--Source--
// PRINT_DEBUG defined somewhere else or here
#if PRINT_DEBUG
void printDebug(const Basic* p) {
// Lengthy debug print
}
#else
void printDebug(const Basic* p) {}
#endif
如果你对这篇内容有疑问,欢迎到本站社区发帖提问 参与讨论,获取更多帮助,或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱,如果其他用户或者作者回复了您的评论,将不能在第一时间通知您!
发布评论
评论(5)
与所有此类问题一样,答案是 - 如果这对您来说真的很重要,请尝试该方法并检查发出的汇编语言。
As with all questions like this, the answer is - if it really matters to you, try the approach and examine the emitted assembly language.
如果编译器在编译时知道 printDebug 函数的实现,它可能会优化此代码。如果 printDebug 在另一个目标模块中,则可能只能通过链接器使用整个程序优化来优化。但测试这一点的唯一方法是读取编译器生成的汇编代码。
如果你已经有 PRINT_DEBUG 宏,你可以通过 TRACE 定义的方式扩展它:
Compiler possibly may optimize this code, if it knows printDebug function implementation at compilation time. If printDebug is in another object module, this possibly may be optimized only by linker, using the whole program optimization. But the only way to test this is to read compiler-generated Assembly code.
If you already have PRINT_DEBUG macro, you can extend it by the way as TRACE is defined:
这样,预处理器将在所有调试代码到达编译器之前将其删除。
This way the preprocessor will strip all debug code before it even gets to the compiler.
目前大多数优化都是在编译时完成的。一些编译器如 LLVM 能够在链接时进行优化。这是一个非常有趣的想法。我建议你看一下。
等待此类优化,你可以做的有以下几件事。定义一个宏,允许您根据是否定义了 DEBUG 来包含以下语句。
您可以像这样使用它,
这已经比
注意您可以像关键字一样使用它更具可读性
Currently most of the optimizations are done at compile time. Some compilers as LLVM are able to optimize at link time. This is a really interesting idea. I suggest you to take a look at.
Waiting for these kind of optimization, what you can do is the following. Define a macro that let you include the following statement depending on whether DEBUG is defined or not.
You can the use it like this
which is already much more readable than
Note that you can use it as if it was a keyword
呃,为什么不以不同的方式使用预处理器宏呢?
就在我的头顶上,类似这样的东西:
errm, why not use the pre-processor macro differently?
Just of the top of my head, something like: