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)
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)
My current understanding is like this. Please correct me if I am wrong. When I include a C++ library (e.g. open source project) to my project I have to include the .h files so that the compiler knows about the interface of the included library. The compiled code of the included library is then linked by the linker.
But now during compilation, the included header file needs another dependency. If I would include the header file of this dependency won't this turn into some recursive loop until every dependency is included? Why is it needed? Shouldn't be this the concern of the linker? The compiled library contains the dependency.
I stumbled over this project using Xcode 9.4.
A compiler translates code into machine language. The said code is then strung together with other machine code using a linker. Google more on what I wrote, if confused; it is a simplification missing finer details.
When you type #include <cstdint> for example, a preprocessor, which is another separate program, does a pattern substitution, if you will, on #include <cstdint> and replaces that line with the whole contents of the cstdint.hh file. The substitute happens before the translation process to machine code even begins.
Usually, these #include <...> files are written carefully so that you do not need to chase other #include. However, that is not a guarantee.
The risk you identify exists. It's not automatic, though. If a.h includes b.h which includes c.h, there is no problem with nested includes.
You could have a problem if a.h includes both b.h and c.h, and b.h also includes c.h indirectly. The risk here isn't so much recursion, but double-definition of the contents of c.h.
The usual solution is that every header starts with
#ifndef A_H_INCLUDED
#define A_H_INCLUDED
// actual contents of "a.h"
and ends with
#endif // A_H_INCLUDED
Now, the second inclusion of c.h is harmless. When this happens, C_H_INCLUDED will be already defined by the first inclusion, so the second inclusion is wholly skipped. Some compilers are smart enough to recognize this pattern and won't even read c.h the second time, saving a few milliseconds of disk I/O.
The linker can't solve this, because the double-definition problem happens before the linker is involved. It happens at the level of individual Translation Units. A Translation Unit is basically a single .cpp file after all its .h files have been included. Each TU is handled individually by the compiler, and it's this compiler which trips over the double definitions. The linker cares a bit less about duplications. Duplicate function definitions are a problem for the linker, class definitions are not.
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.
I have "Hello World" code that uses function fhi from another hi.cpp file that has it's header.
Correct my if my understanding is wrong according following:
I can do include cpp file like #include "c:\c\hi.cpp" instead of using header without any problems except that fact that it looks more readable in header file.
If I include header like sample in my main program hi.h, must hi.h include hi.cpp, or it is done automatically according the same file name hi. I'm wondering how compiler knows where is function fhi body.
Is it possible to have different names for header and cpp files?
Programm:
#include "stdafx.h"
#include "c:\c\hi.h"
int _tmain(int argc, _TCHAR* argv[])
{
fhi(1);
return 0;
}
hi.h
#include <cstdlib>
#include <iostream>
int var;
int fhi(int f);
hi.cpp
#include <cstdlib>
#include <iostream>
int fhi(int f)
{
return 0;
}
must hi.h include hi.cpp
No. hi.h contains only declarations, that can be other by other .cpp files.
I'm wondering how compiler knows where is function fhi body.
It doesn't. You need to compile all *.cpp files into the object files. In your case, you will have two object files: program.o and hi.o. The linker can now take these two object files, and spit out the executable. References to other functions(in this case the actual definition of fhi(..)) is resolved in this stage.
Also why are you using absolute paths in #includes? It will break when you move the "c" directory around.
What normally happens is that the build system compiles the .cpp files into object files, that then are used to build the main executable. The means to tell this to the build system vary greatly.
One important point is that your hi.cpp must include hi.h. You should also put an include guard in hi.h, to make it safe to be included more than once in a translation unit.
I can do include cpp file like #include "c:\c\hi.cpp" instead of using
header without any problems except that fact that it looks more
readable in header file.
yes, you can do so but it is not recommended, one of the problems is encapsulation; you are not hiding implementation details. readability as you mention is also a concern, a header is easier to read since it clearly shows what methods are public.
If I include header like sample in my main program hi.h, must hi.h
include hi.cpp, or it is done automatically according the same file
name hi. I'm wondering how compiler knows where is function fhi body.
the header needs to be explicitly included in hi.cpp and any .cpp file that use the class defined in the header.
Is it possible to have different names for header and cpp files?
yes but it is not recommended, it makes it more difficult to find things.
as a general rule: think about that other programmers may want to look in your code so you need to structure it so that it is easy to read and understand as well as making it easier for you 2 years down the road to remember where things are.
In Visual Studio all CPP files included in the project will be compiled to produce OBJ files. These OBJ files will be linked together to form the EXE or DLL.
Including files are similar to pasting the contents of the file at that location. The only difference is that this pasting is done by the pre-compiler during compilation.
Finding out where a function body resides is done by the either the compiler if the function is inline or by the linker when the final binary is created.
First, if the header file is in the same directory as the source file including it, you can use just
#include "hi.h"
In other words, you don't have to use a full path. (See e.g. the inclusion of "stdafx.h".)
Second, in your header file you don't need to include other header files, unless you need types from those. In your header file you don't have anything that needed from the header files you include.
Third, you should protect header files header files from being included more than once in the same source file, this can be done with a so called include guard, on in some compiler via a special directive called #pragma once.
Fourth, in your header file you define a global variable var. This variable will then be defined in every source file you include the header file in, which will lead to errors. You need to declare the variable as extern:
extern int var;
Then in one source file you define the variable like you do now.
Fifth, you should never include source files in header file (with some special exceptions that you don't have to think about yet). Instead you add all source files to the project (I assume you are in MS VisualStudio) and it they will all be built and linked together automatically.
Sixth, since you seem to be using VisualC++, then you are probably using something called precompiled headers. This is something the compiler uses to speed up compilation. However, for this to work you have to include "stdafx.h" in all source files. That include actually has to be the first non-comment line in each source file.
I have always seen people write
class.h
#ifndef CLASS_H
#define CLASS_H
//blah blah blah
#endif
The question is, why don't they also do that for the .cpp file that contain definitions for class functions?
Let's say I have main.cpp, and main.cpp includes class.h. The class.h file does not include anything, so how does main.cpp know what is in the class.cpp?
First, to address your first inquiry:
When you see this in .h file:
#ifndef FILE_H
#define FILE_H
/* ... Declarations etc here ... */
#endif
This is a preprocessor technique of preventing a header file from being included multiple times, which can be problematic for various reasons. During compilation of your project, each .cpp file (usually) is compiled. In simple terms, this means the compiler will take your .cpp file, open any files #included by it, concatenate them all into one massive text file, and then perform syntax analysis and finally it will convert it to some intermediate code, optimize/perform other tasks, and finally generate the assembly output for the target architecture. Because of this, if a file is #included multiple times under one .cpp file, the compiler will append its file contents twice, so if there are definitions within that file, you will get a compiler error telling you that you redefined a variable. When the file is processed by the preprocessor step in the compilation process, the first time its contents are reached the first two lines will check if FILE_H has been defined for the preprocessor. If not, it will define FILE_H and continue processing the code between it and the #endif directive. The next time that file's contents are seen by the preprocessor, the check against FILE_H will be false, so it will immediately scan down to the #endif and continue after it. This prevents redefinition errors.
And to address your second concern:
In C++ programming as a general practice we separate development into two file types. One is with an extension of .h and we call this a "header file." They usually provide a declaration of functions, classes, structs, global variables, typedefs, preprocessing macros and definitions, etc. Basically, they just provide you with information about your code. Then we have the .cpp extension which we call a "code file." This will provide definitions for those functions, class members, any struct members that need definitions, global variables, etc. So the .h file declares code, and the .cpp file implements that declaration. For this reason, we generally during compilation compile each .cpp file into an object and then link those objects (because you almost never see one .cpp file include another .cpp file).
How these externals are resolved is a job for the linker. When your compiler processes main.cpp, it gets declarations for the code in class.cpp by including class.h. It only needs to know what these functions or variables look like (which is what a declaration gives you). So it compiles your main.cpp file into some object file (call it main.obj). Similarly, class.cpp is compiled into a class.obj file. To produce the final executable, a linker is invoked to link those two object files together. For any unresolved external variables or functions, the compiler will place a stub where the access happens. The linker will then take this stub and look for the code or variable in another listed object file, and if it's found, it combines the code from the two object files into an output file and replaces the stub with the final location of the function or variable. This way, your code in main.cpp can call functions and use variables in class.cpp IF AND ONLY IF THEY ARE DECLARED IN class.h.
I hope this was helpful.
The CLASS_H is an include guard; it's used to avoid the same header file being included multiple times (via different routes) within the same CPP file (or, more accurately, the same translation unit), which would lead to multiple-definition errors.
Include guards aren't needed on CPP files because, by definition, the contents of the CPP file are only read once.
You seem to have interpreted the include guards as having the same function as import statements in other languages (such as Java); that's not the case, however. The #include itself is roughly equivalent to the import in other languages.
It doesn't - at least during the compilation phase.
The translation of a c++ program from source code to machine code is performed in three phases:
Preprocessing - The Preprocessor parses all source code for lines beginning with # and executes the directives. In your case, the contents of your file class.h is inserted in place of the line #include "class.h. Since you might be includein your header file in several places, the #ifndef clauses avoid duplicate declaration-errors, since the preprocessor directive is undefined only the first time the header file is included.
Compilation - The Compiler does now translate all preprocessed source code files to binary object files.
Linking - The Linker links (hence the name) together the object files. A reference to your class or one of its methods (which should be declared in class.h and defined in class.cpp) is resolved to the respective offset in one of the object files. I write 'one of your object files' since your class does not need to be defined in a file named class.cpp, it might be in a library which is linked to your project.
In summary, the declarations can be shared through a header file, while the mapping of declarations to definitions is done by the linker.
That's the distinction between declaration and definition. Header files typically include just the declaration, and the source file contains the definition.
In order to use something you only need to know it's declaration not it's definition. Only the linker needs to know the definition.
So this is why you will include a header file inside one or more source files but you won't include a source file inside another.
Also you mean #include and not import.
That's done for header files so that the contents only appear once in each preprocessed source file, even if it's included more than once (usually because it's included from other header files). The first time it's included, the symbol CLASS_H (known as an include guard) hasn't been defined yet, so all the contents of the file are included. Doing this defines the symbol, so if it's included again, the contents of the file (inside the #ifndef/#endif block) are skipped.
There's no need to do this for the source file itself since (normally) that's not included by any other files.
For your last question, class.h should contain the definition of the class, and declarations of all its members, associated functions, and whatever else, so that any file that includes it has enough information to use the class. The implementations of the functions can go in a separate source file; you only need the declarations to call them.
main.cpp doesn't have to know what is in class.cpp. It just has to know the declarations of the functions/classes that it goes to use, and these declarations are in class.h.
The linker links between the places where the functions/classes declared in class.h are used and their implementations in class.cpp
.cpp files are not included (using #include) into other files. Therefore they don't need include guarding. Main.cpp will know the names and signatures of the class that you have implemented in class.cpp only because you have specified all that in class.h - this is the purpose of a header file. (It is up to you to make sure that class.h accurately describes the code you implement in class.cpp.) The executable code in class.cpp will be made available to the executable code in main.cpp thanks to the efforts of the linker.
It is generally expected that modules of code such as .cpp files are compiled once and linked to in multiple projects, to avoid unnecessary repetitive compilation of logic. For example, g++ -o class.cpp would produce class.o which you could then link from multiple projects to using g++ main.cpp class.o.
We could use #include as our linker, as you seem to be implying, but that would just be silly when we know how to link properly using our compiler with less keystrokes and less wasteful repetition of compilation, rather than our code with more keystrokes and more wasteful repetition of compilation...
The header files are still required to be included into each of the multiple projects, however, because this provides the interface for each module. Without these headers the compiler wouldn't know about any of the symbols introduced by the .o files.
It is important to realise that the header files are what introduce the definitions of symbols for those modules; once that is realised then it makes sense that multiple inclusions could cause redefinitions of symbols (which causes errors), so we use include guards to prevent such redefinitions.
its because of Headerfiles define what the class contains (Members, data-structures) and cpp files implement it.
And of course, the main reason for this is that you could include one .h File multiple times in other .h files, but this would result in multiple definitions of a class, which is invalid.