Question

I’ve never understood the need of #pragma once when #ifndef #define #endif always works.

I’ve seen the usage of #pragma comment to link with other files, but setting up the compiler settings was easier with an IDE.

What are some other usages of #pragma that is useful, but not widely known?

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 #pragma you found useful?

.

Answers at a glance:

Thanks to all who answered and/or commented. Here’s a summary of some inputs I found useful:

• Jason suggested that using #pragma once or #ifndef #define #endif would allow faster compiling on a large-scale system. Steve jumped in and supported this.
• 280Z28 stepped ahead and mentioned that #pragma once is preferred for MSVC, while GCC compiler is optimised for #ifndef #define #endif. Therefore one should use either, not both.
• Jason also mentioned about #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.
• sblom suggested using #pragma warning to isolate the real problems, and disable the warnings that have already been reviewed.
• Evan suggested using #pragma comment(lib, header) for easy porting between projects without re-setting up your IDE again. Of course, this is not too portable.
• sbi provided a nifty #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.
• Chris provided #pragma region to be able to collapse code with custom message in MSVC.

Whoa, wait, what if I want to post about not using #pragmas unless necessary?

• Clifford posted from another point of view about not to use #pragma. Kudos.

I will add more to this list if the SOers feel the urge to post an answer. Thanks everyone!

Answer 1

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.