What is the difference between doing a #include in a .h file and in a .c file?
For example, I have the file a.h and a.c which have the class A. I use class A in class B (b.h, b.c). What is the difference between doing an include:
#include "a.h"
in b.h vs b.c?
Usually, the class definition is typically in your .h file, and the implementation is in your .c(pp) file.
One advantage of doing #include "a.h" in your b.c file, rather than in your b.h file, is that whenever a.h changes, not only b.c but also any other file that includes b.h will have be recompiled.
Also, you're kind of unnecessary exposing implementation details of B to anyone using b.h. The idea is that b.h should not contain additional info that is of no interest to someone using class B (not because it's secret, but because people don't care and you don't want to bother them with it).
There's no need to force anyone including b.h, to indirectly include a dozen of other .h files as well (because they're #included in b.h), just because you happen to use that stuff in b.c. Avoid clutter.
So if possible, it's best to #include "a.h" in b.c !
But this is not always possible. If you're just using A inside b.c, and there are no references to A in b.h, then it's OK. Also, if b.h only contains pointers to A (i.e. as members, function arguments or return values) but no 'type dependent' references, you could also put just this in b.h:
class A;
And still keep #include "a.h" in your b.c. But if there are more references or dependencies on a.h, that anyone including b.h really couldn't do without, then #include "a.h" should go in b.h
There is No difference in including a header file in .h or .c file.
The contents of the included file are just copy pasted in to the file in which you include it.
If you put the include directive in your header file, other files that include that header file will also get the included header.
foo.h:
#include "dependency.h"
bar.h:
#include "foo.h"
In this case, bar.h has both foo.h and dependency.h.
#include "a.h" expands to the contents of a.h.
If #include "a.h" is placed in b.h, then a.h will be copied into b.h during compilation.
If #include "a.h" is placed in b.c, then a.h will be copied into b.c during compilation instead.
.h files put at top of .c or .h files before compile
but .c files compile separately then link to getter to make executable file
You can include .c files - but by convention you do not.
.h files are for declarations - i.e. the .c file is the definition and the this .h file is going to do this. It is like the .h file is the contents of the cook book, and the .c file is the actual recipes.
Related
I just started learning C++ and have trouble understanding the concept of header and source files, specifically which ones I'm supposed to include where.
Suppose I have the classes A and B, each of whose contents are seperated into a header file and a source file, and I have a file in which I want to use those classes.
├ A.h
├ A.cpp
├ B.h
├ B.cpp
└ Main.cpp
Which file do I need to include where, and is it possible to compile/link all files with a single command?
Which file do I need to include where
#include directive in fact is very simple preprocessor directive, which just adds content of the specified file into the target file. Conventionally you keep declaration of functions in a header file and definition of the said functions in the corresponding cpp file, and thus you at least want to have the header included there (in your case A.cpp includes A.h and B.cpp includes B.h). Additionally you include headers in any file where you use the functions declared in the headers (e.g. if you use declarations of A.h and B.h in Main.cpp you include those files as well).
P.S. You, however, can define everything right in the header file, next to declarations, but as I said earlier preprocessor doesn't do anything fancy - it just adds the content of the include in the target file, and you usually don't want to have all definitions in place, because each translation unit which has it included will have the same definitions repeated over and over again.
You include what you need.
If A.cpp needs A.h then it should include it. Same for B.cpp probably needing to include B.h.
If Main.cpp uses A and B then it should include A.h and B.h.
Main.cpp should not rely on indirect includes. For example of A.h does include B.h then Main.cpp using both A and B should still include A.h and B.h even if the code would compile if Main.cpp would only directly include A.h (and by that also indirectly including B.h.)
In Which order?
If you follow the rule of always including what you use (rather than relying on indirectly including a header or rely on some other header being included before) then the order of #include directives should not matter. Changing order of includes breaking a build hints on a problem with includes in one of the headers that should be fixed. If you do things right then order of includes is just a matter of style.
Let's pretend my .h file for the creation of precompiled headers looks like the following:
stdafx.h
#include "A.h" //an external library
.. and "A.h" includes a bunch of other headers:
A.h
#include "B.h" //other headers from an external library included by "A.h"
#include "C.h"
//...
Will precompiled headers be also generated for "B.h" and "C.h" (and the header files that these two files include, and so on...), or do I have to include "B.h" and "C.h" in my "stdafx.h" also?
Yes, the precompiled state will include B and C.
Precompilation works by running the compiler as far as the end of stdafx.h and dumping its state to the disk, then restoring that state before compiling the body of each source file. Everything the compiler sees when compiling stdafx.h goes into that state.
(Put it another way: the process of compiling stdafx.h is exactly the same regardless of whether you're generating the precompilation state or just compiling a source file "normally" - it's just that in the precompilation case the compiler stops at the end of the file. It couldn't treat B and C any differently even if it wanted to.)
Please find here below a simple example.
I know that a .hpp file has to include or forward declare everything it uses
I wonder if it is best practice to include all .hpp files that are used in the .cpp file as well.
I am asking this because I recently saw on a new project I am working on, that people tend to avoid including headers in a lot of cases.
In this case: is it good to include b.hpp in a.cpp?
I know it has already been included by including a.hpp, but I personally feel that if a symbol appears in a .cpp, it should be included (or forward declared if possible)
a.hpp
#pragma once
#include "b.hpp"
class C; //forward declaration of C
class A
{
public:
B get_b();
private:
B _b;
C* _c;
};
a.cpp
#include "a.hpp"
//needed or I can leave it out, since B is included already in a.hpp?
#include "b.hpp"
B A::get_b()
{
return _b;
}
Try to move #includes to .cpp files how much you can. It reduces compilation time and avoids propagating declarations along whole project. So, if you can just include b.hpp in the .cpp file.
Once you include b.hpp in the header file, you don't need to include it in the .cpp file.
Including it again in the .cpp file has no effect due to header guards (if you put them).
There are two main concerns with regards to which files to include in a .cpp (and .hpp)
1) Compile time: Reducing the number of includes to reduce compile time
Roughly: Only include files that contain class data/function members or inline functions/templates that you use. If you only reference a class, a forward declaration is going to compile much faster than the whole include file.
2) Fragility: Not depending on an include file including something you need
If a.hpp includes b.hpp and you need somthing defined in b.hpp (see above) and then the implementor of a.hpp stops requiring a.hpp, your code will break
All of this is deterministic and effort should be put in to get it right
I'm new to programming and the topic of header files is sort of bogging me down after I started using a lot of them. In addition to that I'm trying to use precompiled headers. I'm also using the SFML library so I have those headers that also have to be included.
Right now I have stdafx.h, main.cpp, then classes A, B, C, and D contained within A.h, A.cpp, B.h, B.cpp, C.h, C.cpp, D.h, and D.cpp.
What order would I go about including the headers in all files if
all classes contain an instance of an SFML class
class D contains an instance of class A and class C
class C contains an instance of class B
My code: (note: all headers have header guards)
stdafx.h:
#include <SFML/Graphics.hpp>
#include <iostream>
A.h
#include "stdafx.h"
class A
{
//sfml class
};
A.cpp
#include "stdafx.h"
#include "A.h"
B.h
#include "stdafx.h"
class B
{
//sfml class
};
B.cpp
#include "stdafx.h"
#include "B.h"
C.h
#include "B.h"
class C: public B
{
};
C.cpp
#include "stdafx.h"
#include "C.h"
D.h
#include "A.h"
#include "C.h"
class D
{
A a;
C C; // if left uncommented I recieve a '1 unresolved externals' error
//sfml class
}
D.cpp
#include "stdafx.h"
#include "D.h"
main.cpp
#include "stdafx.h"
#include "D.h"
My philosophy is that in well-written code, header files should include all other header files that they depend on. My reasoning is that it should not be possible to include a header file and get a compiler error for doing so. Therefore, each header file should (after the #ifdef or #pragma once include guard) include all other headers it depends on.
In order to informally test that you've remembered to include the right headers in your header files, *.cpp files should #include the minimum set of header files that should work. Therefore, if there are separate header files for A, B, C and D, and your cpp file uses class D, then it should only include D.h. No compiler errors should result, because D.h #includes A.h and C.h, C.h includes B.h, and A.h and B.h include the SFML header (whatever that is). C.h and D.h can include the SFML header if it seems appropriate, but it's not really necessary, if you can be sure that the dependencies (B.h and A.h) already included it.
The way Visual C++ does "precompiled headers" screws up this logic, however. It requires you to include "StdAfx.h" as the very first header file, which causes many developers to simply put all #includes for the entire project in StdAfx.h, and not to use #include in any of the other header files. I don't recommend this. Or, they will put all external dependencies in StdAfx.h (e.g. windows.h, boost headers) and #include the local dependencies elsewhere so that changing a single header file does not necessarily cause the entire project to rebuild.
The way I write my code, most of my CPP files include StdAfx.h, and the corresponding .H file. So A.cpp includes StdAfx.h and A.h, B.cpp includes StdAfx.h and B.h, and so forth. The only other #includes placed in a cpp file are "internal" dependencies that are not exposed by the header file. For example, if class A calls printf(), then A.cpp (not A.h) would #include <stdio.h>, because A.h does not depend on stdio.h.
If you follow these rules then the order that you #include headers does not matter (unless you use precompiled headers: then the precompiled header comes first in each cpp file, but does not need to be included from header files).
Take a look at a similar question to learn a good approach to authoring headers.
In short, you want to define each header inside a definition guard that prevents headers from being included more then once during compilation. With those in place, for each .h and .cpp file, just include the headers needed to resolve any declarations. The pre-processor and compiler will take care of the rest.
C inherits class B. So, it should see the identifier B. So, include B.h here -
#include "B.h" // Newly added
// Or you can forward declare class B ;
class C: public B
{
};
D has objects of class A, B. So, include headers of A, B in the "D.h" itself.
class D
{
A a; // Should see the definition of class A
C c; // Should see the definition of class B
//sfml class
}
D.cpp
#include "A.h"
#include "C.h"
#include "D.h" // Notice that A.h and C.h should definitely placed before
Note that every header needs to be included in it's corresponding source file. Think of each source file independently and see whether what ever is used is earlier defined or not in the source file.
A.h should include SFML
A.cpp should include A.h
D.h should include SFML, A.h and C.h
D.cpp should include D.h
main.cpp should include whichever of A, B, C, D and SFML that it uses directly.
Generally in a .cpp file I don't include any headers that you know must be included by its corresponding .h because they contain the definitions of data members of classes defined in that .h. Hence, in my code D.cpp would not include A.h. That's just me, though, you might prefer to include it anyway just to remind you that the .cpp file (presumably) uses it.
This leaves stdafx - where you need this depends what uses the things in it. Probably it's needed everywhere, and MSVC doesn't process (or processes but discards?) anything before #include "stdafx.h" in a source file, so it should be the first thing in each .cpp file and appear nowhere else.
All header files should have multiple-include guards.
You could add SFML (or anything else you feel like) to stdafx.h, in which case you might as well remove those includes from everywhere else.
Once you've done this, it no longer matters what order you include the headers in each file. So you can do what you like, but I recommend Google's C++ style guide on the subject (click on the arrow thing), adjusted to account for stdafx.h.
Depends on dependencies. Unlike C# and other similar languages, C++ does things in the order it is written, so there may be an issue. If you do have a problem with the order then it will not compile.
I am making a small C++ framework, which contains many .h and .cpp.
I have created a general include which include all my .h file such as:
framework.h
#include "A.h"
#include "B.h"
#include "C.h"
each .h header are protected with include guard such as
#ifndef A_HEADER
#define A_HEADER
...
#endif
The issues is, I would like to be able to include "framework.h" inside all the sub .h such as, but it cause lots of compiler error:
#ifndef A_HEADER
#define A_HEADER
#include "framework.h"
...
#endif
If instead I use the real header file for each sub header, and the framework.h for what ever use my framework it works fine..
I would just like to include the main header inside all my sub .h so I dont need to include all the dependency everytime.
Thanks :)
Basically what your doing is #include "A.h" in framework.h and #include "framework.h" in A.h. This causes cyclic dependency of the header files and you will get errors such as undefined class A. To solve this, use forward declarations in header file and #include only in corresponding cpp file. If that is not possible then I don't see any other option other than including individual header files.
Just protect the main header with include guards too:
#ifndef FRAMEWORK_H
# define FRAMEWORK_H
# include <A.h>
# include <B.h>
# include <C.h>
#endif
That will prevent recursive inclusion.
You should not including the main header file inside the sub-header files. It should be used to make user's life easier, not yours.
Instead do following:
1) Make forward definitions of all you need in the related sub-header files.
2) Include only needed sub-header files inside CPP files.
3) When using your framework inside an application code (for example), then you could include the main framework header file.
i would recommend using #pragma once, and placing that at the top of all of your header files (framework.h, A.h, B.h, and C.h).
Although, if you'd rather, I think you could fix your problem by simply putting an include guard in framework.h as well.
I guess you have a dependency between - say B and C such that B depends on C, but in framework.h C is included after B.
Circular includes are generally a bad idea in C++. While having header guards will prevent the preprocessor from going into infinite loop (or throwing an error because of this), you will get unexpected compiler errors, because at some point a header file will not be included when if you think it is.
You should include A.h, B.h and C.h from framework.h, and in A.h, do not include framework.h, just forward declare the classes you use from it. Or do it the other way around: include framework.h from A.h, B.h and C.h, and forward declare classes in framework.h. And, of course, put every code that would require any more detailed declarations than for example class A to the .cpp files.