__FILE__、__LINE__ 和 __FUNCTION__ 在 C++ 中的用法

声明:本页面是StackOverFlow热门问题的中英对照翻译,遵循CC BY-SA 4.0协议,如果您需要使用它,必须同样遵循CC BY-SA许可,注明原文地址和作者信息,同时你必须将它归于原作者(不是我):StackOverFlow 原文地址: http://stackoverflow.com/questions/597078/
Warning: these are provided under cc-by-sa 4.0 license. You are free to use/share it, But you must attribute it to the original authors (not me): StackOverFlow

提示:将鼠标放在中文语句上可以显示对应的英文。显示中英文
时间:2020-08-27 16:10:00  来源:igfitidea点击:

__FILE__, __LINE__, and __FUNCTION__ usage in C++

c++debuggingloggingc-preprocessor

提问by Runcible

Presuming that your C++ compiler supports them, is there any particular reason notto use __FILE__, __LINE__and __FUNCTION__for logging and debugging purposes?

假设您的 C++ 编译器支持它们,是否有任何特别的理由使用__FILE__,__LINE__以及__FUNCTION__用于日志记录和调试目的?

I'm primarily concerned with giving the user misleading data—for example, reporting the incorrect line number or function as a result of optimization—or taking a performance hit as a result.

我主要关心的是向用户提供误导性数据——例如,报告不正确的行号或作为优化结果的函数——或者因此而导致性能下降。

Basically, can I trust __FILE__, __LINE__and __FUNCTION__to alwaysdo the right thing?

基本上,我可以信任__FILE____LINE____FUNCTION__永远做正确的事?

回答by Evan Teran

__FUNCTION__is non standard, __func__exists in C99 / C++11. The others (__LINE__and __FILE__) are just fine.

__FUNCTION__是非标准的,__func__存在于 C99/C++11 中。其他(__LINE____FILE__)都很好。

It will always report the right file and line (and function if you choose to use __FUNCTION__/__func__). Optimization is a non-factor since it is a compile time macro expansion; it will nevereffect performance in any way.

它将始终报告正确的文件和行(如果您选择使用__FUNCTION__/ ,则报告功能__func__)。优化是一个非因素,因为它是一个编译时宏扩展;它永远不会以任何方式影响性能。

回答by Johannes Schaub - litb

In rare cases, it can be useful to change the line that is given by __LINE__to something else. I've seen GNU configure does that for some tests to report appropriate line numbers after it inserted some voodoo between lines that do not appear in original source files. For example:

在极少数情况下,将给出的行更改为其他内容会很有用__LINE__。我已经看到 GNU configure 为某些测试执行此操作,以便在未出现在原始源文件中的行之间插入一些伏都教之后报告适当的行号。例如:

#line 100

Will make the following lines start with __LINE__100. You can optionally add a new file-name

将使以下行以__LINE__100开头。您可以选择添加新的文件名

#line 100 "file.c"

It's only rarely useful. But if it is needed, there are no alternatives I know of. Actually, instead of the line, a macro can be used too which must result in any of the above two forms. Using the boost preprocessor library, you can increment the current line by 50:

它只是很少有用。但如果需要的话,我知道没有其他选择。实际上,代替行,也可以使用宏,它必须导致上述两种形式中的任何一种。使用 boost 预处理器库,您可以将当前行增加 50:

#line BOOST_PP_ADD(__LINE__, 50)

I thought it's useful to mention it since you asked about the usage of __LINE__and __FILE__. One never gets enough surprises out of C++ :)

我认为提及它很有用,因为您询问了__LINE__and的用法__FILE__。从 C++ 中你永远不会得到足够的惊喜 :)

Edit:@Jonathan Leffler provides some more good use-cases in the comments:

编辑:@Jonathan Leffler 在评论中提供了一些更好的用例:

Messing with #line is very useful for pre-processors that want to keep errors reported in the user's C code in line with the user's source file. Yacc, Lex, and (more at home to me) ESQL/C preprocessors do that.

对于希望将用户 C 代码中报告的错误与用户的源文件保持一致的预处理器来说,使用 #line 非常有用。Yacc、Lex 和(对我来说更熟悉)ESQL/C 预处理器可以做到这一点。

回答by Mr.Ree

FYI: g++ offers the non-standard __PRETTY_FUNCTION__ macro. Until just now I did not know about C99 __func__ (thanks Evan!). I think I still prefer __PRETTY_FUNCTION__ when it's available for the extra class scoping.

仅供参考:g++ 提供了非标准的 __PRETTY_FUNCTION__ 宏。直到刚才我还不知道 C99 __func__ (感谢 Evan!)。我想我仍然更喜欢 __PRETTY_FUNCTION__ 当它可用于额外的类范围时。

PS:

PS:

static string  getScopedClassMethod( string thePrettyFunction )
{
  size_t index = thePrettyFunction . find( "(" );
  if ( index == string::npos )
    return thePrettyFunction;  /* Degenerate case */

  thePrettyFunction . erase( index );

  index = thePrettyFunction . rfind( " " );
  if ( index == string::npos )
    return thePrettyFunction;  /* Degenerate case */

  thePrettyFunction . erase( 0, index + 1 );

  return thePrettyFunction;   /* The scoped class name. */
}

回答by Craig S

Personally, I'm reluctant to use these for anything but debugging messages. I have done it, but I try not to show that kind of information to customers or end users. My customers are not engineers and are sometimes not computer savvy. I might log this info to the console, but, as I said, reluctantly except for debug builds or for internal tools. I suppose it does depend on the customer base you have, though.

就个人而言,除了调试消息之外,我不愿意将它们用于任何其他用途。我已经做到了,但我尽量不向客户或最终用户显示此类信息。我的客户不是工程师,有时也不精通计算机。我可能会将此信息记录到控制台,但正如我所说,除了调试版本或内部工具之外,我很不情愿。不过,我想这确实取决于您拥有的客户群。

回答by JeffCharter

I use them all the time. The only thing I worry about is giving away IP in log files. If your function names are really good you might be making a trade secret easier to uncover. It's sort of like shipping with debug symbols, only more difficult to find things. In 99.999% of the cases nothing bad will come of it.

我一直在使用它们。我唯一担心的是在日志文件中泄露 IP。如果您的函数名称非常好,您可能会使商业秘密更容易被发现。这有点像附带调试符号,只是更难找到东西。在 99.999% 的情况下,不会有什么不好的事情发生。