"Reprint" #pragma once and #ifndef

Source: Internet
Author: User

This essay is reproduced, the original paste address: #pragma once and #ifndef analysis

In order to avoid the same file being include multiple times, there are two ways in C/s + +, one is #ifndef and the other is #pragma once mode. There is not much difference between the two compilers that can support both, but there are still some subtle differences.
Way One:

#ifndef __somefile_h__
#define __somefile_h__
...//Declaration, definition statement
#endif


Way two:

#pragma once
...//Declaration, definition statement

#ifndef的方式受C/c++ language Standard support. It does not only guarantee that the same file will not be included more than once, but also that two files (or snippets) with exactly the same content will not be included accidentally.
The downside, of course, is that if you accidentally "crash" a macro name in a different header file, it might cause you to see that the header file exists, and the compiler insists it can't find the state of the statement-a situation that is sometimes maddening.
Because the compiler needs to open the header file each time to determine if there is a duplicate definition, Ifndef makes the compilation time relatively long when compiling large projects, so some compilers gradually begin to support the way #pragma once.

#pragma once is generally guaranteed by the compiler: the same file will not be included multiple times. Note that the "same file" here refers to a physical file, not two files of the same content. You cannot make a pragma once declaration for a piece of code in a header file, but only for a file.
The advantage is that you don't have to bother thinking about a macro name, and of course there's no strange problem with the macro name collision. The compilation speed of large projects has thus improved a bit.
The disadvantage is that if a header file has multiple copies, this method does not guarantee that they will not be included repeatedly. Of course, this repetition is easy to detect and correct, compared to the "no claims" issue caused by the macro name collision.

#pragma once way is generated after #ifndef, so many people may not even have heard of it. Now it seems that #ifndef is more admired. Because #ifndef is supported by the C + + language standard and is not subject to any compiler restrictions, the #pragma once approach is not supported by older compilers, and some supported compilers intend to remove it, so it may not be as well-compatible. Generally speaking, when the programmer hears this, will choose the #ifndef way, in order to try to make their code "live" longer, usually prefer to lower some of the compiler performance, this is the programmer's personality, of course, this is a digression.

Also see a usage that puts the two together:

#pragma once
#ifndef __somefile_h__
#define __somefile_h__
...//Declaration, definition statement
#endif

It seems to have the advantage of both. However, as long as the use of #ifndef will be the danger of macro name conflict, and can not avoid support #pragma once compiler error, so mixing the two methods does not seem to bring more benefits, it will make some unfamiliar people feel confused.

Which method to choose, should be understood in two ways, depending on the situation. As long as there is a reasonable agreement to avoid the shortcomings, I think which way is acceptable. This is not the standard or compiler responsibility, should be the programmer himself or a small scope of development norms to be done.

BTW: I see some of the GNU discussions seem to be going on in GCC 3.4 (and beyond). ) version of #pragma once is canceled. In fact, the GCC 3.4.2 and gcc 4.1.1 in my hands still support #pragma once, not even deprecation warning, but GCC2.95 #pragma the once.
VC6 and its later versions also provide support for the #pragma once approach, which should basically stabilize.

"Reprint" #pragma once and #ifndef

Contact Us

The content source of this page is from Internet, which doesn't represent Alibaba Cloud's opinion; products and services mentioned on that page don't have any relationship with Alibaba Cloud. If the content of the page makes you feel confusing, please write us an email, we will handle the problem within 5 days after receiving your email.

If you find any instances of plagiarism from the community, please send an email to: info-contact@alibabacloud.com and provide relevant evidence. A staff member will contact you within 5 working days.

A Free Trial That Lets You Build Big!

Start building with 50+ products and up to 12 months usage for Elastic Compute Service

  • Sales Support

    1 on 1 presale consultation

  • After-Sales Support

    24/7 Technical Support 6 Free Tickets per Quarter Faster Response

  • Alibaba Cloud offers highly flexible support services tailored to meet your exact needs.