Closed. This question is opinion-based. It is not currently accepting answers.
Want to improve this question? Update the question so it can be answered with facts and citations by editing this post.
Closed 3 years ago.
Improve this question
A similar issue has already been discussed (C/C++ include header file order), but this thread makes no mention of forward declarations. If I summarize what I've read online so far:
Everyone agrees that the corresponding header for the .cpp file should go first. This ensures that the header files has everything it needs.
Beyond that, there seems to be no consensus. The Google guidelines (https://google.github.io/styleguide/cppguide.html) suggest including headers from system -> other libs -> project. Many people on SO suggest the exact opposite. It seems to be a matter of personal preferences.
Regarding forward declarations, is there any reason to add them before/after the include headers? I don't see why it would matter (Is a class declaration allowed after a class definition?), but maybe I am missing something.
I think this is one of those questions that has no one right answer.
The way I think of it (and its by no means the absolute answer) is from an encapsulation point of view and I tend to do the opposite of the google guidelines for this reason:
If you include your project headers first you are less likley to hit issues where your header relies on some system include that went before it because you will just get a compile error... so therefore I find you see issues faster by putting the system includes last.
Same thing for the forward declarations - if you need them and they are not provided by a header - then add them after the includes because the headers should not need them (otherwise it would be in the header) and so you only declare it as/when you need it...
That is more-or-less my reasoning - but as I say, if your headers are designed correctly then you could do it either way...
Related
Closed. This question is opinion-based. It is not currently accepting answers.
Want to improve this question? Update the question so it can be answered with facts and citations by editing this post.
Closed 6 years ago.
Improve this question
I'm just curious about whether using windows.h a good thing (PS : I don't care about OSindependent code) ,it seems really good with thousands of functions . So is it good ? and where is its Dir ?
Good, bad or indifferent depends on the view.
If you are programming Windows-specific applicaitons, then you'll probably not be able to avoid using it. For generic applications that work on any platform, it's obviously bad, and if you DON'T know that you need some headerfile, don't include it. But do include things that you do need, even if it "works" without - you never know when something changes that header file that dragged in something else you didn't include in your code, and breaks the code.
"Where is it's dir", I presume means "what directory will I find it in", and I'm afraid that's not something I, or anyone else, can tell you. It depends on which compiler you are using, and how/where it was installed - and in some cases, you need to install it separately, in other cases it's included with the compiler. Since there are at least half a dozen different current compilers that work under Windows, and several that no longer are being maintained, but still "works" [to varying degrees], it would be rather pointless to even try to answer this.
Microsoft does publish an "SDK", which contains the headers, should they not be part of your installation of the compiler:
https://dev.windows.com/en-us/downloads/windows-10-sdk
Closed. This question needs details or clarity. It is not currently accepting answers.
Want to improve this question? Add details and clarify the problem by editing this post.
Closed 7 years ago.
Improve this question
This was asked on a past exam. Given that the header file is custom I am assuming not because they are just variations of the main(){ header correct?
I'm not sure if I understand the question, but I would say yes, they are optional. You could write all of your (custom) functions, classes, etc. in one file if you wanted.
I'm new here so I can't comment, but the question is a bit confusing to me. But here is what I think, I hope it helps:
Header files contain functions, variables, classes etc. in C and C++. Header files that come pre-built with your compiler must be included before you can use any function or anything thing inside that file.
Now referring to a custom header files, you may choose to create a file containing specific information to use in your programs, often to make your code look more organize or to create reusable libraries. Those are OPTIONAL simply because you can manage to create all your functions, variables and classes in the same file containing your main(){}. It might look messy, impossible to read but possible to achieve.
BTW I'm not sure about what you mean by header files being variations of the main(), but agreeing with Trevor Hickey, they shouldn't have a main() function since they are not compilable, they don't execute the functions they just hold the information.
Closed. This question is opinion-based. It is not currently accepting answers.
Want to improve this question? Update the question so it can be answered with facts and citations by editing this post.
Closed 8 years ago.
Improve this question
Is it good practice to use your choice of either/both include guards and #pragma once in every header file, or just those with something such as a class declaration?
I am tempted to put it in every header, but I'm afraid it would be unneeded and only add to the compile time. What is good practice or common to do?
Let me clarify: I understand the difference between the two. I am asking whether by experience programmers use it in every file or just those that require it.
Summarizing the comment by Galik and what I realized:
Include guards should be put in every header file in the case that something in the future conflicts. Furthermore, the small time it takes the compiler to process the include guards will make the compilation faster since the extra header does not need to be processed.
#pragma once is compiler specific, while normal include guard definitions, should work with any c++ preprocessor.
Thus for sake of portability, always stick to "ye good old" include guards idiom.
The use of include guards is essential to prevent multiple symbol declaration errors in your code. You shouldn't bother about assumptions, or implications, how this is handled by the c++ preprocessor (modern ones are pretty optimized to do this efficiently).
If you want your code to be portable to all C++ compilers you'll need to use include guards. If you feel the compiler you use is inferior and benefits from the use of #pragma once you can also add this pragma: compilers not understanding it will just ignore it. Personally, I don't bother with use of #pragma once. It is a solution to a non-existing problem: compilers can absolutely detect include guards to avoid opening files already included.
Closed. This question needs to be more focused. It is not currently accepting answers.
Want to improve this question? Update the question so it focuses on one problem only by editing this post.
Closed 8 years ago.
Improve this question
I am having one big project in which I have kept all Headers in one common header file and where all I needed i included that header file.. by doing like this project is working fine but if I do changes in any header file its taking too much to build so I want to know is there any resolution to reduce the build time?
This isn't really specific to MFC, it is a general C++ thing. Basically don't put everything in 1 common header. Make use of forward declarations wherever possible. Use include guard macros in headers unless doing some special preprocessor magic.
Use a precompiled header and only put stuff in there that very rarely changes. Don't let this header get too big though as that can decrease build times.
Reduce the amount of code in headers. In some cases the pimpl idiom can make headers more terse and less prone to change due to 'internal' implementation changes at the cost of run-time efficiency.
http://www.cplusplus.com/forum/articles/10627/
Closed. This question needs to be more focused. It is not currently accepting answers.
Want to improve this question? Update the question so it focuses on one problem only by editing this post.
Closed 8 years ago.
Improve this question
My question is "when we come across a new function, how can we figure out what is the minimum header file/library to include?
In other words, is there a systematic way to figure out the required header/library for a certain function?
To clarify:
I googled and found ofstream to be handy for output I/O. I needed to include <fstream> to be able to use ofstream. how can I determine these two libraries and how to figure out the minimum required one? (well in this case, I googled again! or obviously I could search the filesystem for any file .h or .soor .cpp or ... that define this function )
Reading the documentation is the preferred way.
Searching the filesystems for the function name way too often leads astray - there are many headers that rely on code in a file that includes it in turn.
The cppreference site is a pretty good resource on the standard.
For platform specifics:
If you're on Windows, MSDN tells you exactly which header and library to include.
Linux and Unixes have their man pages.
OS X has the XCode documentation and man pages.
Well you have answered your own question. Either google it or check the API documentation, they should mention what is to be included. For example "man strcpy" tells me that I need to include #include <string.h>.
Additionally, you can also try to understand the relationship among the APIs. For example, fstream provides ofstream and ifstream, so including fstream will help in that case.
When it comes to standard C or C++, I usually use cppreference to find which header file is related with what I want to use.
If it is Unix-related, then the man pages are my friend.