Quoting from Microsoft documentation, There is no advantage to use of both the #include guard idiom and #pragma once in the same file.
Answers to previous related questions on stackoverflow also confirm that it is pointless to have both. See below, for instance:
Header guards and pragma once
The boost library's vector.hpp file, however, starts thus:
#ifndef BOOST_ASSIGN_STD_VECTOR_HPP
#define BOOST_ASSIGN_STD_VECTOR_HPP
#if defined(_MSC_VER)
# pragma once
#endif
...
#endif
That is, it includes both the guard idiom as well as the pragma once. Is there any reason why boost header files have both?
Technically #pragma once is not standard C++, whereas header guards are. They will not conflict with each other if you have both.
The reason boost likely has both, as alluded to by the #if defined(_MSC_VER) is that if you're not using MSVC then you need something to act as your header guard, so they fall back to the other method.
Since boost strives to be cross-platform they are trying to ensure their code works on compilers that don't support #pragma once, though all of the big modern compilers I can think of do support it, as enumerated on wikipedia.
Related
In the stl implementation that comes along with Visual Studio 12.0 the numeric header looks like this
#pragma once
#ifndef _NUMERIC_
#define _NUMERIC_
// shortened for the sake of readibility
.
.
.
#endif /* _NUMERIC_ */
I know that #pragma once is not standard conform.
Nevertheless, why did they implement a double header guard?
#pragma once: The same file will not be included multiple times
include guard idiom：uses preprocessor macro definitions to prevent multiple inclusions of the contents of the file.
According to the Doc
There's no advantage to use of both the include guard idiom and
#pragma once in the same file. The compiler recognizes the include guard idiom, and implements the multiple-include optimization the same
way as the #pragma once directive if no non-comment code or
preprocessor directive comes before or after the standard form of the
idiom
I suggest you could refer to the link:https://stackoverflow.com/a/13339535/11872808
I would like to use clan-tidy. The program should check if I do have header guards, which is why I set the flag llvm-header-guard. Unfortunately this checks if the header guards are llvm-style, which I don't want. I want to use #pragma once.
Does anyone have an idea how to tell clang-tidy to check for #pragma once instead of llvm-style header guards?
There is no such check in clang-tidy.
#pragma once is not part of the C++ standard (for good reasons) and until it becomes a part of the standard there is no reason to add it to clang-tidy.
You can write your own check but I don't think it's worth the effort.
I'm building my own terminal app project in C++ and I'm asking myself if standard library has ifdef or ifndef preprocessors instructions. I want to know that because I need to create different header files which need some standard library headers such as "string" and some others, i don't want to include the same library 3 or more times because it makes the program heavier.
For example i wrote on my header files something like this to prevent the .h file to be included more than once:
#ifndef myheader_h
#define myheader_h
// my file code here
#endif
I tried compiling but the compiler say me nothing about errors or warnings.
I also tried to read the standard-library source code (https://en.cppreference.com/w/cpp/header) and I haven't found any preprocessor rule like ifdef or ifndef.
Should i include standard library headers like this?
#ifndef string_h
#define string_h
#include <string>
#endif
I hope my question isn't already asked because I haven't found it while searching it.
Updates
To some who said "you're not in the position where you need to worry about" and who said "it costs very little if it has proper include guards", I meant: program's heaviness is important, I want to make it slighter so I don't want to entirely include the same file multiple times. Have std lib files proper include guards? (my header files have them, didn't know std lib files)
There is no requirement for the standard header files to #define any specific pre-processor symbols to make sure they can be #included multiple times.
Having said that, any sane implementation would make sure that they can be #included multiple times without adversely affecting application code.
Turns out, that is a requirement by the standard for most headers (Thanks, #Rakete1111).
From the C++ standard
A translation unit may include library headers in any order ([lex]). Each may be included more than once, with no effect different from being included exactly once, except that the effect of including either <cassert> or <assert.h> depends each time on the lexically current definition of NDEBUG.
Not only that, they are very likely to be using the #pragma once directive. Hence, even if you use #include multiple times for the same header, they are going to be read only once.
In summary, don't worry about standard header files. If your header files are implemented correctly, your application would be just fine.
Those preprocessor directives you're talking about are called "header guards", and the standard library headers definitely have them (or some other mechanism that does the same thing) like all other proper header files. Including them multiple times shouldn't cause any problems, and you only need to worry about these when you're writing your own header files.
The "source code" that you're reading is just the documentation which says how the header files should work, but it doesn't provide the actual code. To see the code, you can look in the header files provided by your compiler. For example, the <iostream> header in Visual Studio has both #pragma once and header guards:
#pragma once
#ifndef _IOSTREAM_
#define _IOSTREAM_
//...
#endif /* _IOSTREAM_ */
The headers provided by the GCC compiler also has header guards:
#ifndef _GLIBCXX_IOSTREAM
#define _GLIBCXX_IOSTREAM 1
//...
#endif /* _GLIBCXX_IOSTREAM */
I'm asking myself [sic] if standard library has ifdef or ifndef preprocessors instructions
The standard doesn't specify whether there are ifdef-style header guards, although it does require that multiple inclusion is protected in some manner. I took a look at a random header of stdlibc++ standard library implementation. It does have header guards.
i don't want to include the same library 3 or more times because it makes the program heavier
Including a header file multiple times does not make a program "heavier".
Should i include standard library headers like this?
#ifndef string_h
#define string_h
#include <string>
#endif
That is not necessary, or particularly useful.
Just seen this inside <boost/asio.hpp>
#ifndef BOOST_ASIO_HPP
#define BOOST_ASIO_HPP
#if defined(_MSC_VER) && (_MSC_VER >= 1200)
# pragma once
#endif // defined(_MSC_VER) && (_MSC_VER >= 1200)
/// ....
#endif // BOOST_ASIO_HPP
Disregarding the _MSC_VER preprocessor checks, what is the benefit of having the #pragma once in this case? Doesn't the preprocessor header guard ensure in all cases and on all platforms, the header contents are only ever included once?
#pragma once specifies that the file will be included (opened) only once by the compiler when compiling a source code file. This can reduce build times as the compiler will not open and read the file after the first #include of the module.
If you don't #pragma once, the file will be opened each time it is needed and compiler will stop parsing it on #ifndef BOOST_ASIO_HPP, if it has been defined.
Specifies that the file will be included (opened) only once by the compiler in a build. This can reduce build times as the compiler will not open and read the file after the first #include of the module
And one more related question from SO
Yes header guards ensures that the header contents are included only once. but here you are using #pragma for checking another definition and not include file.
The below link is existing question on header guards in SO.
Purpose of Header guards
#pragma once has the same purpose, but include guards are intended to require a deeper analysis to ensure a file is included exactly once - e.g.
// somerandomfileinmyproject.cpp
#undef BOOST_ASIO_HPP
#include <bost/asio.cpp>
Unless the compiler does handle such cases correctly, it still needs to open the file and pass it through the preprocessor even though it has been included before.
You can reproduce the effect of the #pragma once in a standard way using the following:
#if !defined GUARD_SYMBOL
#include "GUARDED_FILE"
#endif
although it is much more verbose. As others have said, it helps with compilation times since the file is not searched for / opened instead of opening the file and ignoring everything inside it - the file still has to be parsed by the preprocessor.
To avoid conflicts with winsock2.h, I want to wrap my include of windows.h with WIN32_LEAN_AND_MEAN (I undef it after windows.h so as not to interfere with applications that include my headers). Doing this causes timeval to be undefined when winsock2.h isn't included. Including time.h doesn't define timeval either.
How can I get timeval defined (a) without having to include winsock2.h, (b) not requiring applications that include my headers to include winsock2.h before my headers, (c) allowing application to include winsock2.h if they need them, and (d) not having to define timeval myself, because it may already be defined by a header the parent application is including?
Remember that WIN32_LEAN_AND_MEAN is a compiler performance optimisation. Using it makes your apps compile somewhat faster at the expense of omitting some less-used parts of the Windows API.
You could use one of the more granular disables (NOIMM, etc), but these have even less impact on compile time than the LEAN_AND_MEAN one does.
Unless your project is very large and has long, onerous compile times I would simply stop using WIN32_LEAN_AND_MEAN.
Martyn
I don't define either of the LEAN_AND_MEANs, instead I explicitly do the following for each of the 'NOs' prior to including windows.h
// Exclude Input Method Manager (International stuff...one day)
#if !defined NOIMM
#define NOIME
#define NOIMM
#endif
// Exclude Metafile API
#if !defined NOMETAFILE
#define NOMETAFILE
#endif
This allows me to use the same StdAfx.h. With VS2010 I can include Winsock2 after windows.h without conflicts.
Stdafx is a little longer, but clearly documents what is included and excluded.
This is how I handle problems with winsock2.h (assuming Visual C++):
I configured the build system to always pass in /D_WINSOCKAPI_ to the compiler on the command line so that no winsock header files are ever implicitly included.
When I want to include winsock2.h, I do it via a proxy header file that does some preprocessor magic for me.
This is how my header file works:
#pragma push_macro("_WINSOCKAPI_")
#undef _WINSOCKAPI_
#include <winsock2.h>
#pragma pop_macro("_WINSOCKAPI_")
If you do this then you don't need to #define WIN32_LEAN_AND_MEAN and you can use winsock2.h only when needed.
I don't think what you want is possible. The timeval struct is defined in winsock.h and winsock2.h, thus you have to include one of those to get the definition. If you don't define WIN32_LEAN_AND_MEAN, windows.h will include winsock.h; this makes it impossible to include winsock2.h. If you define WIN32_LEAN_AND_MEAN, neither of the winsock header files are automatically included thus you don't get the definition for timeval. I think your best option is to require applications to include one of the winsock headers explicitly.