你用#pragma编写的什么代码你发现有用吗？ [英] What code have you written with #pragma you found useful?
问题描述
当 #pragma once 的需要-a-safe-include-guard> #ifndef #define #endif 始终有效。
我已经看到了使用 #pragma comment 链接到其他文件，但使用IDE设置编译器设置更容易。
#pragma 的其他用法是有用的，但不是广为人知？
编辑：
我不是 也许我应该多说一下这个问题：
你用 #pragma 发现有用吗？
。
感谢所有回答和/或评论的人。以下是我发现有用的一些输入的摘要：
- Jason建议使用
#pragma once或#ifndef #define #endif将允许在大型系统上更快的编译。 cpu c> c> c> c>#ifndef #define #endif。 - Jason还提到了
#pragma pack的二进制兼容性，而Clifford反对这一点，由于可能的可移植性和字节顺序问题。 Evan提供了一个示例代码，Dennis通知大多数编译器将强制填充以进行对齐。 - sblom建议使用
#pragma warning - Evan建议使用
#pragma comment（lib，header）在项目之间轻松移植，而无需重新设置IDE。当然，这不是太便携。 - sbi为VC用户提供了一个漂亮的
#pragma消息信息。 James进一步，允许错误或警告匹配MSVC的消息，并会正确显示，如错误 - Chris提供
#pragma region，以便能够在MSVC中使用自定义邮件折叠代码。
哇，等等，如果我不想使用#pragmas发布 p> 如果SOers感到有意发布答案，我将向此列表添加更多内容。感谢大家！ 每个pragma都有它的用途，或者他们不会在那里。 edit：回答意见：想象你有一个200kB头文件。使用once，编译器加载一次，然后知道它不需要包括头在下次看到它引用的所有。使用#if它必须每次加载并解析整个文件，以确定所有的代码被禁用的if，因为if必须每次评估。在大型代码库上，这可能会产生重大差异，但实际上（尤其是预编译头文件）可能不会。 pragmapack当你需要结构体的二进制兼容性。 编辑：对于二进制格式，你提供的字节必须完全匹配所需的格式 - 如果你的编译器添加一些填充，它会拧紧数据对齐和损坏数据。因此，为了将序列化为要传递到/来自操作系统调用或TCP数据包的二进制文件格式或内存中结构，使用直接映射到二进制格式的结构比成员序列化（memberwise serialization逐个写入字段） - 它使用较少的代码和运行速度更快（在嵌入式应用程序中至关重要，即使在今天）。 pragma错误message是非常方便的，特别是内部条件修饰块（例如错误：ePhone的版本未实现，消息：额外的调试和性能分析代码在此版本中启用） pragmawarning（特别是push& pop）对于临时禁用恼人的警告非常有用，特别是当包含写得不好的第三方标题（充满警告）时 - 尤其是如果你构建与警告级别4。 编辑：良好的做法是在构建中实现零警告，以便当警告发生时，您注意到并立即修复。你当然应该在你自己的代码中修复所有的警告。然而，一些警告根本不能固定，不告诉你什么重要。此外，如果您使用第三方库，您无法更改他们的代码以修复警告，您可以通过禁用库的警告从您的构建中删除垃圾邮件。使用push / pop允许您仅在库包含期间选择性禁用警告，以便您自己的代码仍然由编译器检查。 I've never understood the need of I've seen the usage of What are some other usages of Edit: I'm not just after a list of #pragma directives. Perhaps I should rephrase this question a bit more: What code have you written with . Answers at a glance: Thanks to all who answered and/or commented. Here's a summary of some inputs I found useful: Whoa, wait, what if I want to post about not using #pragmas unless necessary? I will add more to this list if the SOers feel the urge to post an answer. Thanks everyone! Every pragma has its uses, or they wouldn't be there in the first place. pragma "once" is simply less typing and tidier, if you know you won't be porting the code to a different compiler. It should be more efficient as well, as the compiler will not need to parse the header at all to determine whether or not to include its contents. edit: To answer the comments: imagine you have a 200kB header file. With "once", the compiler loads this once and then knows that it does not need to include the header at all the next time it sees it referenced. With #if it has to load and parse the entire file every time to determine that all of the code is disabled by the if, because the if must be evaluated each time. On a large codebase this could make a significant difference, although in practical terms (especially with precompiled headers) it may not. pragma "pack" is invaluable when you need binary compatibility for structs. Edit: For binary formats, the bytes you supply must exactly match the required format - if your compiler adds some padding, it will screw up the data alignment and corrupt the data. So for serialisation to a binary file format or an in-memory structure that you wish to pass to/from an OS call or a TCP packet, using a struct that maps directly to the binary format is much more efficient than 'memberwise serialisation' (writing the fields one by one) - it uses less code and runs much faster (essential in embedded applications, even today). pragma "error" and "message" are very handy, especially inside conditional compliation blocks (e.g. "error: The 'Release for ePhone' build is unimplemented", message: "extra debugging and profiling code is enabled in this build") pragma "warning" (especially with push & pop) is very useful for temporarily disabling annoying warnings, especially when including poorly written third-party headers (that are full of warnings) - especially if you build with warning level 4. edit: Good practice is to achieve zero warnings in the build so that when a warning occurs you notice it and fix it immediately. You should of course fix all warnings in your own code. However, some warnings simply cannot be fixed, and do not tell you anything important. Additionally, when using third party libraries, where you cannot change their code to fix the warnings, you can remove the 'spam' from your builds by disabling the library's warnings. Using push/pop allows you to selectively disable the warnings only during the library includes, so that your own code is still checked by the compiler. 这篇关于你用#pragma编写的什么代码你发现有用吗？的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持IT屋！
#pragma 。 Kudos。
如果你知道你不会将代码移植到不同的编译器，pragmaonce只是简单的打字和整洁。它应该也更有效，因为编译器不需要解析头，以确定是否包括其内容。
#pragma once when #ifndef #define #endif always works.#pragma comment to link with other files, but setting up the compiler settings was easier with an IDE.#pragma that is useful, but not widely known?#pragma you found useful?
#pragma once or #ifndef #define #endif would allow faster compiling on a large-scale system. Steve jumped in and supported this.#pragma once is preferred for MSVC, while GCC compiler is optimised for #ifndef #define #endif. Therefore one should use either, not both.#pragma pack for binary compatibility, and Clifford is against this, due to possible issues of portability and endianness. Evan provided an example code, and Dennis informed that most compilers will enforce padding for alignment.#pragma warning to isolate the real problems, and disable the warnings that have already been reviewed.#pragma comment(lib, header) for easy porting between projects without re-setting up your IDE again. Of course, this is not too portable.#pragma message trick for VC users to output messages with line number information. James took one step further and allows error or warning to match MSVC's messages, and will show up appropriately such as the Error List.#pragma region to be able to collapse code with custom message in MSVC.
#pragma. Kudos.
