c++ - 您使用#pragma 编写的哪些代码有用？

Question

就目前而言，这个问题不适合我们的问答形式。我们希望答案得到事实、引用或专业知识的支持，但这个问题可能会引起辩论、争论、投票或扩展讨论。如果您觉得这个问题可以改进并可能重新打开，visit the help center为指导。




9年前关闭。




我一直不明白 #pragma once 的需要当 #ifndef #define #endif 总是有效。

我看过#pragma comment的用法与其他文件链接，但使用 IDE 设置编译器设置更容易。
#pragma还有哪些其他用法？这很有用，但并不广为人知？

编辑:

我不仅仅是在#pragma 指令列表之后。或许我应该重新表述一下这个问题:

你用 #pragma 写了什么代码你觉得有用吗？

.

答案一目了然:

感谢所有回答和/或评论的人。以下是我发现有用的一些输入的摘要:

Jason 建议使用 #pragma once或 #ifndef #define #endif将允许在大型系统上更快地编译。史蒂夫加入并支持这一点。

280Z28走在前面提到了#pragma once MSVC 首选，而 GCC 编译器针对 #ifndef #define #endif 进行了优化.因此，应该使用其中之一，而不是两者都使用。

Jason 还提到了 #pragma pack为了二进制兼容性，Clifford 反对这一点，因为可能存在可移植性和字节序问题。 Evan 提供了示例代码，Dennis 告知大多数编译器将强制执行填充以进行对齐。

sblom 建议使用 #pragma warning隔离真正的问题，并禁用已经审查过的警告。

Evan 建议使用 #pragma comment(lib, header)以便在项目之间轻松移植，而无需再次重新设置您的 IDE。当然，这不是太便携。

sbi 提供了一个漂亮的 #pragma message VC 用户输出带有行号信息的消息的技巧。 James 更进一步，允许 error或 warning匹配 MSVC 的消息，并将适本地显示，例如错误列表。

克里斯提供 #pragma region能够在 MSVC 中使用自定义消息折叠代码。

哇，等等，如果我想发布关于除非必要不使用 #pragmas 的帖子怎么办？

克利福德从另一个角度贴出关于不使用#pragma .荣誉。

如果 SOers 有发布答案的冲动，我会在此列表中添加更多内容。谢谢大家!

Answer 1

每个 pragma 都有其用途，否则它们一开始就不会存在。

如果您知道不会将代码移植到不同的编译器，则编译指示“一次”只是减少输入和整理。它也应该更有效，因为编译器根本不需要解析头来确定是否包含其内容。

编辑:回答评论:假设您有一个 200kB 的头文件。使用“once”，编译器加载一次，然后知道它不需要在下次看到引用时包含头文件。使用 #if 它必须每次加载和解析整个文件以确定所有代码都被 if 禁用，因为每次都必须评估 if。在大型代码库中，这可能会产生显着差异，尽管在实际中(尤其是预编译头)可能不会。

当您需要结构的二进制兼容性时，pragma "pack"是无价的。

编辑:对于二进制格式，您提供的字节必须与所需的格式完全匹配 - 如果您的编译器添加了一些填充，它会搞砸数据对齐并破坏数据。因此，对于序列化为二进制文件格式或您希望传入/传出操作系统调用或 TCP 数据包的内存结构，使用直接映射到二进制格式的结构比“成员序列化”更有效(一个接一个地编写字段)-它使用更少的代码并且运行得更快(即使在今天，嵌入式应用程序中也是必不可少的)。

pragma "error"和 "message"非常方便，尤其是在条件编译块中(例如“错误:'Release for ePhone' 版本未实现”，消息:“在此版本中启用了额外的调试和分析代码”)

pragma "warning"(尤其是 push & pop)对于暂时禁用恼人的警告非常有用，尤其是在包含写得不好的第三方 header (充满警告)时 - 特别是如果您使用警告级别 4 构建。

编辑:好的做法是在构建中实现零警告，以便在出现警告时您会注意到它并立即修复它。您当然应该在自己的代码中修复所有警告。但是，有些警告根本无法修复，并且不会告诉您任何重要信息。此外，在使用第三方库时，您无法更改其代码来修复警告，您可以通过禁用库的警告来从构建中删除“垃圾邮件”。使用 push/pop 允许您仅在库包含期间有选择地禁用警告，以便编译器仍然检查您自己的代码。