I've searched all over for some clarification on what
#pragma once
actually does and can't find definitive answers for some questions I still have.
Does
#pragma once
insure that the header file it is included in is only called once AS WELL AS that the headers which are included in said header file are not yet included? Also, if it is only called once, does that mean a .cpp file that needs a particular header will not be able to access it? If a header file is marked with
#pragma once
and included in a .cpp, can that header file be used again elsewhere?
These are the sorts of clarifications I am not finding. Sorry if there is documentation that clarifies this somewhere, but I really couldn't find any thing specific enough.
#pragma once only guards a single file in a single translation unit, not counting its sub-hierarchy of inclusion. (However, if the file's second inclusion is prevented, it doesn't have an opportunity to doubly-include anything else.)
You can still include it again from another .cpp.
The file is usually identified by its inode number.
Note that #pragma once is strictly nonstandard, and most still prefer traditional #ifndef header guards.
#pragma once causes the current source file to be included only once in a single compilation.
It's essentially similar to #include guards.
Does #pragma once insure that the header file it is included in is only called once AS WELL AS that the headers which are included in said header file are not yet included?
The pragma doesn't affect other headers. if the header with the pragma 'a.h' includes 'b.h', 'b.h' can be included again via a third header or directly.
Also, if it is only called once, does that mean a .cpp file that needs a particular header will not be able to access it?
You can include the header from anywhere you want, as many times as you see fit.
If a header file is marked with #pragma once and included in a .cpp, can that header file be used again elsewhere?
Yes, this is the normal practice with headers.
Where's the catch?
If you really need to include the headers more than once and every include performs a different operation than don't use pragma once or a sentry macro. These cases are not common.
A benefit to pragma once is that it saves you from bugs like having 2 header files that by chance have the same sentry macro. this can happen when 2 header files have the same file name and same coding style for macro names.
Related
I have an age-old question.
I'm developing an infrastructure code in C++ which has a lot of headers to be included in each header file.
I ideally would like to have everything included in a header file and then just to include that header file. That of course creates infinite-loop problem where a header is included in a header that includes the same header.
Doing #ifndef or #pragma once is also not going to help.
Is there any other clever way to achieve this?
Thanks
That of course creates infinite-loop problem where a header is included in a header that includes the same header.
Simply exclude the "superheader" from the set of headers that the "superheader" includes. That way you don't get the problem.
That said, doing this is likely going to cause translation units including the "superheader" to include headers unnecessarily which may adversely affect compilation times. As such, I don't recommend this approach.
I am having trouble understanding an answer I saw in another post. It said that it is good practice to define a struct in a separate .h file so it can be used in other files. I think that is great and it solves my current dilemma, however I have a question about compilation and makefiles. I am only familiar with having header files that are associated with .cpp files at the moment.
Can someone explain how that implementation would look when I have a .h and no .cpp? Do I need an implementation file as well? Also, how do I link the header in a makefile? Currently I only know how to compile a .cpp & header into a .o file and link them.
Thanks, and sorry for taking us back to c++ kindergarten. This is a new revelation and seems like a good one.
You don't need a matching source file (.c or .cpp) for every header .h file.
Having header files without corresponding source files is just fine.
When you #include some header file, you can think of it as a kind of "copy and paste" operation: the preprocessor copies the content of the header file, and pastes it in the point of inclusion.
(Well, there are some details to consider here, for example the presence of a #pragma once directive or some #ifdef inclusion guard can prevent multiple inclusions of the same header file in a given project.)
The C and C++ compilers will then process the whole "compilation unit", i.e. the current source file with all the included headers.
The key concept is that you define the struct/class in a .h header, so that you can use it in multiple .cpp files. Whenever you need struct foo defined in foo.h, you #include "foo.h". You don't need to directly compile the header file, it will be pulled in by whichever source file uses it. Therefore you don't need a make target for .h in normal circumstances.
If the definition in the header is never used, it won't be pulled in and that's it.
In my project i have a Header file common.h which include many headers in it.Some of the files include Common.h and some other header which are already present in Common .h So In the Pre-Processing stage many functions get prototyped twice(Once from the Included header and other from Gui.h).I was wondering is this would cause any issue in long run.
Please suggest..Thanks in advance..
Headers should have include guards so that they are only processed once:
#ifndef SOME_UNIQUE_STRING
#define SOME_UNIQUE_STRING
// Everything else here
#endif
By "Everything" I mean "everything", starting with your #includes if any.
SOME_UNIQUE_STRING could be the name of the module as long as it is unlikely to coincide with another define somewhere else.
If you look in your library headers, you will notice they use include guards like this.
As Chemistpp suggested,
#pragma once
is a good option to try, though it is non-standard.
Check out the advantages and disadvantages listed in the link.
I don't understand why header guards are not used in pre-compiled headers... Any ideas?
Because "stdafx.h" has to be the first include in .cpp files, not anywhere else.
If all you do is include other headers, there's no need. If those files can not be included multiple times, they will have their own header guards. stdafx.h itself doesn't care how many times it is included unless you're using it wrong.
Usually, stdafx.h will be included only once per cpp file, as the first statement, and normally, no other files will include it. So, chances of recursively including stdafx.h are minimal, thus the "unnecessariness" of the include guard.
I would still advise to use one, just in case, or potentially use #pragma once at the top of the file.
I do not know the code of the precompiled header, but I guess it contains a "#pragma once", which has the same effect but only works in VS (at least it's not standard). I remember wizard created MFC files using these.
My c++ program is using a separate header file (Let's call it myHeader.h) and therefore includes it (#include "myHeader.h"). In my program I need to use another header file (Let's call it another.h). Does it make a difference whether I put the #include "another.h" directive in the cpp file or in myHeader.h?
If it's not used in the .h file, then there will be no difference in compilation success/failure.
However, it is recommended to put include for header files you only need in the implementation in the .cpp files for the following reasons:
for encapsulation reasons - no one needs to know what you include solely for the implementation.
Including a file A.h in a header file B.h will also make any file that includes B.h include A.h. That can cause major dependency issues between seemingly unrelated files.
for the above reason, it can also increase build time substantially (every file you include is copied in your compilation unit).
If you need to include a header only in your cpp file then you should include it in your cpp file.
If you include it in your header it will add unneeded dependencies for everyone else who includes your header. This can explode if the unneeded headers you include also include other unneeded headers of their own.
The answer to your question is "No". However, you should try to avoid making unnecessary include statements in your .h files because it will induce longer build times. It is also better for encapsulation reasons as well.
Assuming all your include guards are in place etc then no.
It's best to think of how the user will use the code and try and avoid surprises for them.
In general you should avoid complex trees of include files included form other include files - although precompiled headers on modern compilers help.
BUT you should also make sure that you have all the advanced declarations in place so that the order of includes in a cpp file doesn't matter.
No difference really. Header files and cpp files can both include other files. The included files are effectively copied into the text stream.
There is a difference - every time your h file is included, any files included in that h file are included as well - I haven't kept up-to-date with modern C++ compilers, but this used to really increase compile time.
It also increases the physical dependency of the source - John Lakos' Large Scale C++ Software Design addresses this, and is well worth a read on structuring c++ programs. It's published in 1996, so it's not based around current practice, but the advise on structure is worth knowing.