Suppose I have a header file which should be including another header file but doesn't (for whatever reason). For example:
myHeader.h
#ifndef MYHEADER_H
#define MYHEADER_H
struct i
{
uint32_t field; // Forgot to include <cstdint>
};
#endif
This mistake can be easily hidden in the .c/.cpp files. For instance like this:
someFile.cpp
#include "myOtherHeader.h" // <cstdint> gets included through this file
#include "myHeader.h"
struct i someStruct;
someFile.cpp will compile just fine and hide the fact that I missed including cstdint in myHeader.h. This isn't a problem here, but suppose when I want to use myHeader.h in some other .cpp file, that could cause a problem.
Is there a simple way to detect this omission of the header file? There are unpleasant ways, like manually looking over the file (but that is tedious and error prone), or creating a dummy .cpp file and including just the header file in question (but that isn't scalable to a large number of header files). Is there some static analysis tool or method that would check this for me?
You do it manually.
It's kind of silly to sit through and write code to check for you and paste it in every file when you can spend a 100th of that time just heading to the top and pasting the include statement in.
Related
If a library is included in a class header and then this header is included in another class do I have to include the library again?
For example:
#ifndef A_H
#define A_H
#include<someLibrary.h>
class A{
...
}
#endif
Then another class includes the A.h header
#include<A.h> //include class A
class B{
...
}
Do I have to include the "someLibrary.h" in class B?
No, #includes are transitive.
However, if your second file itself uses symbols from someLibrary, it's good style to re-include the header. That way you're not "hoping and praying" that you never remove the intermediate include. Your codebase will be more robust if every source file #includes everything that it directly needs. Header guards prevent this from being a wasteful policy.
The preprocessor #include directive does exactly what the name implies, it actually includes the file at the place of the directive.
Simple example: Lets say we have to files, first a header file named a.h
// Our class
class A
{
// Stuff for the class
};
// End of the class
Then a source file a.cpp:
// Include header file
#include "a.h"
// Header file included
int main()
{
// Code
}
The preprocessor generates a single file looking like
// Include header file
// Our class
class A
{
// Stuff for the class
};
// End of the class
// Header file included
int main()
{
// Code
}
This inclusion is recursive, so if a header file is including another header file, that other header file will also be included.
The source file generated by the preprocessor is called a translation unit and is what the compiler actually sees.
The above is a simplification on how a modern preprocessor works, and while it can be run separately to create a preprocessed source file, it's more common that the preprocessor is part of the compiler to streamline the parsing process.
You should also note that the terminology you use is not correct. A library can (and usually do) have one or more header files, which are used when compiling your source code. A library then often (but not always) contain a special library file that is linked with the object files created by the compiler.
A library that has no linker library is called a header only library.
You don't include classes or libraries, you just include headers, and that is a textual operation (a bit like a copy & paste done by the preprocessor).
Read more about the C/C++ preprocessor, and the GNU cpp.
You can ask your compiler to show you the preprocessed form of your source file foo.cc, e.g. with g++ -Wall -C -E foo.cc (it will spills on stdout the preprocessed form)
For a small project (e.g. less than 200KLOC), having just one single common header file included by all your translation units is sensible (and I believe that having many small header files is bad habit, so I usually put more than one class definition per header file). BTW, that (single header file) approach is friendly for precompiled headers. Some people prefer to have several of their own #include-d subheaders in that single header.
Notice that most C++ standard headers (like <map> or <vector>....) bring a lot of text, so you don't want to have tiny compilation units (on my Linux system, #include <vector> is dragging more than ten thousand lines, so having only a few dozen of your source code lines after is inefficient for the compiler)
Also notice that C++ class definitions usually have lots of inlined member functions (and you practically want to give the body of that inlined function in the same header file). So C++ header code tends to be quite big...
(some people prefer to break a single header file in many subheaders, which are always included together)
In Eclipse IDE(C++), how can I add a common header file to all existing source and header files? I have a common header file created say "common.h". This file needs to be included in all the source files (.c) as well all the header files (.h). Rather than manually adding #include "header.h", how can I do it through Eclipse in one go? My header "header.h" has
#ifndef HEADER_H
#define HEADER_H
....
#endif
I am basically looking for a short cut to avoid the manual task.
In fact, this is part of a voluminous exercise where I would like to replace all std:;cout with myout (say) where myout is an object of my own class MYIOSTREAM subclassed from iostream and common.h is the header containing that class declaration. Possible other that manually opening each of the files and ...
In my current project. A lot of my .cpp and .h files have plenty of includes in them such as 6 or 7 of headers declared in the following manner.
#ifndef A_Header
#include "a.h"
#endif
#ifndef B_Header
#include "b.h"
#endif
I wanted to know would it make sense if I wrapped all of these headers (used in the project) in a single header and then declare that header in each source file as such
#ifndef Wrapper_Header
#include "wrapper.h" /*This would contain a collection of all headers*/
#endif
Any suggestions and drawbacks of this plan that I am not anticipating?
That's totally bizarre.
Every header should contain a header guard:
#ifndef THIS_HEADER
#define THIS_HEADER
/* contents of the header */
#endif
This goes inside the header, not in the including .cpp file. The compiler detects the header guard and avoids re-reading all the text when it's included again. This can save seconds of compilation time.
If your headers have that, then the guards in the .cpp file are extraneous and you should remove them. 6 or 7 headers isn't a lot, but that silly boilerplate does sure add up.
Never wrap your headers, always be explicit, make it clear what is included, and do not include what you do not need.
Potatoswatter is correct
But I like to add use "forward declaration".
I am sure you can google it.
I have a code in which I #include<linux/videodev2.h>. There are three files:
one header file- includes: stdint.h and stdlib.h. Defines a couple of functions, a struct, say abc, and some #define macros. One of the functions is
int func(int, uint32_t, size_t, abc*);
one cpp file with a lot of methods, including definition of the functions in the .h file.
one main.cpp which has main() which has a function call to the method in the .h file (complete file below). This file is only for testing purposes.
#include "head.h"
int main() {
func(5, (uint32_t)5, (size_t)5, 0);
return 0;
}
What is see is a curious case:
If I include linux/videodev2.h only in .h file, uint32_t and other things defined in this header are not accessible by the .cpp files. (erros I get are: uint32_t was not declared in this scope, and uint32_t does not name a type, among others). This happens even if the first line of the .h file is #include<linux/videodev2.h>
If I include the videodev2 header in both the cpp files, it works only if I import it (videodev2) before the .h file.
If I use func(5, (uint32_t)5, (size_t)5, (abc*)0); in the main.cpp file, I get the error that abc is not declared in this scope.
I am compiling using the command: g++ main.cpp head.cpp
I am unable to figure out why is this. I would like to include the videodev2 header in the .h file since, it is almost certain that the code using the .h file will be dependent on it. But it seems that including it in .h file has no effect at all.
I must be honest here. This was C code which I had to convert to C++. I know that I am not conforming to the best practices and standards. But why is this behaviour seen?
Remember that the #include directive indicates to the preprocessor the contents of the specified file should be treated as if they appeared directly in the source file in place of the directive (paraphrased from MSDN).
With that in mind, it seems like you are encountering improper order of #includes and also missing #includes. My guess would be that you are not including your own header file in your .cpp files. This would explain cases one and three. Consider the following files:
// header.h
// #include <linux/videodev2.h> <-- Option 1
class A {
void func(uint32_t var);
};
// header.cpp
void A::func(uint32_t var) {
// implementation
}
// main.cpp
// #include <linux/videodev2.h> <-- Option 2
#include "header.h"
// #include <linux/videodev2.h> <-- Option 3
int main() {
// implementation; something creates an instance of A and calls func
}
Now, Option 1 is not exactly desirable; it's good practice to avoid #includes in header files because they can increase build times and create unwanted dependencies. However, it will ensure that the types header.h requires are there for it to use. The essential bit is that the contents of linux/videodev2.h have to appear before the contents of header.h, anywhere that header.h is #included.
This brings me to Option 2. Option 2 will also compile correctly, because linux/videodev2.h is included before your header, and your header relies on types defined in it. Also important is that both main.cpp and header.cpp must #include "header.h", because they reference symbols declared in it.
If you were to go with Option 3, you would get compilation errors that the type uint32_t is not defined, and the compiler would point to your header file. This is because the contents of the header file appear before the contents of linux/videodev2.h, and so the compiler does not yet understand what the type uint32_t is when it encounters it.
So, given all that, you have choices: include `linux/videodev2.h' before each include of your own header file, or include it directly in your header file. I mentioned earlier that the latter is not good practice, but for your particular case, it might be the better option of the two, in case your header file needs to be included in many .cpps.
I think this would be a good opportunity to dive into precompiled headers, but I'm not as well-versed in them, so I'd leave it to someone who has more experience to explain them.
Hope this helps :)
Found the answer. There was .h.gch file in the directory. I didn't know about precompiled header. Thanks ktodisco for the insight. I still have no idea why that file was there in the first place.
When coding in either C or C++, where should I have the #include's?
callback.h:
#ifndef _CALLBACK_H_
#define _CALLBACK_H_
#include <sndfile.h>
#include "main.h"
void on_button_apply_clicked(GtkButton* button, struct user_data_s* data);
void on_button_cancel_clicked(GtkButton* button, struct user_data_s* data);
#endif
callback.c:
#include <stdlib.h>
#include <math.h>
#include "config.h"
#include "callback.h"
#include "play.h"
void on_button_apply_clicked(GtkButton* button, struct user_data_s* data) {
gint page;
page = gtk_notebook_get_current_page(GTK_NOTEBOOK(data->notebook));
...
Should all includes be in either the .h or .c / .cpp, or both like I have done here?
Put as much as you can in the .c and as little as possible in the .h. The includes in the .c are only included when that one file is compiled, but the includes for the .h have to be included by every file that uses it.
The only time you should include a header within another .h file is if you need to access a type definition in that header; for example:
#ifndef MY_HEADER_H
#define MY_HEADER_H
#include <stdio.h>
void doStuffWith(FILE *f); // need the definition of FILE from stdio.h
#endif
If header A depends on header B such as the example above, then header A should include header B directly. Do NOT try to order your includes in the .c file to satisfy dependencies (that is, including header B before header A); that is a big ol' pile of heartburn waiting to happen. I mean it. I've been in that movie several times, and it always ended with Tokyo in flames.
Yes, this can result in files being included multiple times, but if they have proper include guards set up to protect against multiple declaration/definition errors, then a few extra seconds of build time isn't worth worrying about. Trying to manage dependencies manually is a pain in the ass.
Of course, you shouldn't be including files where you don't need to.
Put as many includes in your cpp as possible and only the ones that are needed by the hpp file in the hpp. I believe this will help to speed up compilation, as hpp files will be cross-referenced less.
Also consider using forward declarations in your hpp file to further reduce the include dependency chain.
If I #include <callback.h>, I don't want to have to #include lots of other header files to get my code to compile. In callback.h you should include everything needed to compile against it. But nothing more.
Consider whether using forward declarations in your header file (such as class GtkButton;) will suffice, allowing you to reduce the number of #include directives in the header (and, in turn, my compilation time and complexity).
I propose to simply include an All.h in the project that includes all the headers needed, and every other .h file calls All.h and every .c/.cpp file only includes its own header.