I was just wondering what the difference between .cpp and .h files is? What would I use a header file (.h) for and what would I use a cpp file for?
In general, and it really could be a lot less general:
.h (header) files are for declarations of things that are used many times, and are #included in other files
.cpp (implementation) files are for everything else, and are almost never #included
Technically, there is no difference. C++ allows you to put your code in any file, with any format, and it should work.
By convention, you put your declarations (basically, that which makes up your API) in the .h files, and are referred to as "headers". The .cpp files are for the actual "guts" of your code - the implementation details.
Normally, you have the header files included with #include by other files in your project (and other projects, if you're making a library), so the compiler can get the interface required to compile. The implementation, in the .cpp files, is typically implemented so there is one .cpp file "filling in" the implementation per .h file.
By convention, .h files is something that you #include. CPP files are something you add to your project for compiling into separate object file, and then passing to the linker.
The .h file is called the header file. You usually put your interface there (the stuff you want to be public). The cpp file is where you actually implement your interface.
First, both are text files that contain code for the C++ compiler or pre-processor. As far as the system is concerned there is no difference.
By convention different file name extensions are used to indicate the content of files. In C programs you tend to see .h and .c files while in C++ .hpp and .cpp serve the same purposes.
The first group, .h and .hpp files, called header files, contains mostly non-executing code such as definitions of constants and function prototypes. They are added to programs via #include directive and used not only by the program or library in question but by other programs or libraries that will make use of them, declaring interface points and contracts defining values. They are also used to set metadata that may change when compiling for different operating systems.
The second group, .c and .cpp files, contain the executing parts of the code for the library or program.
Correct me if I'm wrong but,
When you #include something, it more-or-less inserts the entire included file into the one with the include command; that is, when I include, say "macros.h" in "genericTools.cpp", the entire contents of "macros.h" is placed in "genericTools.cpp" at that point. This is why you need to use things like "#pragma once" or other protections, to prevent including the same file twice.
Of note, templated code needs to be entirely in the file you're going to be including elsewhere. (I'm unsure of this - can template specializations be ommited from the included files, and linked like a normal function?)
The .cpp that is the implementation file is our actual program or code.
When we need to use different inbuilt functions in our code, we must include the header file that is .h files.
These .h files contains the actual code of the inbuilt functions that we use hence we can simply call the respective functions.
Therefore, while we compile our code we can see more number of lines compiled than what we have actually coded because not only our code is compiled but along with that the (code of the) functions (that are included in .h files) are also compiled.
Related
What's the difference between including a header(.h files) and a C++ file(.cpp files)? When I create a class, I create a .h file and .cpp file. If I want to use an object of this class should I include both of these files or not? In which cases should I include the .cpp file?
What files are called, and what their contents is, are entirely convention. If you like to confuse people, you could call your header files something.b and your source files something.r - this will of course mean nothing useful to most people, and some people may think your files contain the language R rather than C++ sources. And your editor will probably not understand that it's C or C++ in files called .b - and build tools such as Make, scons, CMake, etc will probably not understand how to compile the your files without being "told". [Compilers also look a the filename extension to determine if it's supposed to compile as C++ or C, which of course will not work with "unconventional names"]
What is important is not what the files are called, but what they actually contain. A header (what most people call something.h) file should be such that it can be included anywhere, and any number of times in your project [exceptions do exist, where header files are not really meant to be included more than a single time in the entire project - for example a version.h which declares a string that describes the current version number].
A source file (what is conventionally called something.cpp, typically, should be passed to the compiler directly to be compiled, and not used as #include "something.cpp". However, it is the CONTENT that determines this, not the name of the file. It's just badly named files if you use them that way.
In summary: The compiler just reads the source file passed in, then "inserts" the #include into the stream of code that it compiles, as if it was pasted into the original source file. The compiler doesn't really care what your file names are, where they came from, or what their content is, as long as the compiler is "ok" with the compilation as a whole.
There is no difference to include .cpp and .h files from point of view of compiler. But The content of .cpp and .h is different in common case. The .cpp files is for implementation of class, functions, static objects, and the .h files is for class definition. If you include the .cpp file into another .cpp file the content is duplicated and will fail at link stage becouse the naming collisions.
What's the difference between including a header(.h files) and C++ file(.cpp files)?
Supposed the .cpp file contains some function definitions, the latter option usually doesn't work well with commonly used build systems, and ends up with multiple definition errors, when the .cpp is included by more of one translation unit.
The exception might be having inlined all of your function definitions in the .cpp file.
In the very principle it's that the C/C++ preprocessor just expands the text found in either file type into the current translation unit. The file extension doesn't play any role here.
There is no difference. Both are handled by the preprocessor as plain text for concatenation to a single file. However, including a source might have a undesirable result (multiple definitions of variables/functions). Header files are usually protected by inclusion guards (#ifndef HEADER_H or a #pragma once) to prevent duplication of their content.
Note: The compiler does it's work after preprocessing (or invokes the preprocessor before compiling).
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.
I am reading the book Absolute C++ 5th edition.
In page 716,
I don't really understand why it needs include "pfarray.cpp"
Is include "pfarray.h" not enough?
More specifically, even if we have declarations in .h file but implementations in .cpp files, when we still have to include .cpp file?
Thank you in advance.
You don't have to.
A translation unit is a group of files with definitions and declarations. Compiling a translation unit, the compiler needs to know everything about declarations and re-parse them again and again. The definitions on the other hand can be compiled just once and reused for another units.
A translation unit can be separated in .h and .cpp files. You should put the declarations in .h and definitions in .cpp files to obey one definition rule. This approach also reduces compilation time.
Writing template-d classes and functions (without specialization), some coders (a bad habit in my opinion) will put the implementations in the .cpp files and they have to include them at the end of its corresponding .h file or in a .cpp file which needs them. It's just confusing. A better naming convention is to rename these type of .cpp files to .impl.cpp and including them at the end of its .h file.
When you write #include anything.any_extension, the extension doesn't really matter to the preprocessor. It's really like a "take the contents from that file and paste it into this file" kind of brute mechanism. So you can include anything without error provided that the code inside is legit, and you can name a header file with any extension. So you can even name them with a .txt extension and it wouldn't really matter to the preprocessor.
I would suggest that the practice of including source files is rather confusing, mainly from a build standpoint since it's not very clear whether a source file (cpp, cc, etc) is supposed to be built as a separate object file to link against or #included or both.
Yet it's sometimes done anyways. For example, pfarray.cpp might contain an implementation for a template since templates typically need their full implementation visible at compile time at the site generating the code, and sometimes authors establish a habit of #including files with source file extensions to avoid putting the implementation details into the same header file while uniformly conforming to a style that favors putting all such details into files named with a source file convention.
Another reason this can be done, but I don't think it's the reason it was done in your case, is as a build optimization (see Unity builds). It can sometimes be more efficient to compile and link fewer files, so using #include for source files can be a crude way to fuse them all together into a single build target.
In Python whenever I had a bunch of functions that I wanted to use across multiple programs I'd make another .py file and then just import that wherever I needed it. How would I do that in C/C++? Do I dump both prototype and implementation into an .h file? or do I need to place the function prototypes in the .h file and the implementations in a separate .cpp file with the same name as the .h file and #include the .h wherever I need it?
You need to do a couple of things:
Add the prototype to a header file.
Write a new source file with the function definitions.
In a source file that just wants to use the shared function, you need to add #include "header.h" (replacing header.h with the name of the file from step 1) someplace before you try to call the shared function (normally you put all includes at the top of the source file).
Make sure your build compiles the new source file and includes that in the link.
A couple of other comments. It's normal to have foo.h as the header for the foo.c but that is only a style guideline.
When using headers, you want to add include guards to protect against the multiple include issue.
In C/C++ we usually put declarations in .h files and implementation in .c/cpp files.
(Note: there're many other ways, for example the include, templates, inline, extern, ... so you may find some code only in header files or only in c/cpp files - for example some of the STL and templates.)
Then you need to "link" the file with your program, which works like the "import" in Python interpreter but actually works in static linking object files together into a single executable file.
However the "link" command and syntax depends on your compiler and OS linker. So you need to check your compiler for more information, for example "ld" on UNIX and "link.exe" on DOS/Windows. Moreover, usually the C compiler will invoke the linker automatically.
For example, say you have 2 files: a.c and b.c (with a.h and b.h), on gcc:
gcc -o a.out a.c b.c
On MSVC:
cl a.c b.c
There are two ways to approach this that differ only slightly. As others have said, the first steps are:
-Create a header file which contains your function prototypes. You'll want to mark this with
# ifndef myheader_h
# define myheader_h
// prototypes go here...
# endif
to prevent problems with multiple inclusions.
-Create a .c file which contains the actual definitions.
Here's where the solutions branch.
If you want to include the source directly in your project, make the .c file part of your compilation stage as well as your link stage.
However, if you really plan on using this across multiple projects, you'll probably want to compile this source file independently, and reference the object file from your other projects. This is loosely what a "library" is, though libraries may consist of multiple object modules - each of which has been compiled but not yet linked.
update
Someone pointed out that this really only keeps the header from being included in a single cpp file. News flash: that's all you need to do.
Compilers treat each cpp file individually. The header files included by each cpp source file tell the compiler, "hey! This thing is defined in another source file! Assume references that match this prototype are A-OK and keep moving on."
The LINKER, on other other hand, is responsible for fixing up these references, and IT will throw a fit if the same symbol is defined in multiple object files. For that to happen, a function would have to be defined in two separate source files - a real definition with a body, not just an extern prototype - OR the object file that contains its body/definition would have to be included in the link command more than once.
Re:"inline"
Use of "inline" is meant as an optmization feature. Functions declared as inline have their bodies expanded inline at each place where they are called. Using this to get around multiple definition errors is very, very bad. This is similar to macro expansion.
See Francis's answer. The sentence that you wrote, "or do I need to place the function prototypes in the .h file and the implementations in a separate .cpp file with the same name as the .h file and #include the .h wherever I need it?", is pretty-much correct. You don't have to do things exactly this way, but it works.
It's up to you how you do this, The compiler doesn't care. But if you put your functions in a .h file, you should declare them __inline otherwise if you include the header file in more than one .cpp file, you will have multiply defined symbols.
On the other hand, if you make them __inline, you will tend to get a copy created in each place that you use the function. This will bloat the size of your program. So unless the functions are quite small, it's probably best to put the functions in a .cpp and create a parallel .h with function prototypes and public structures. This is the way most programmers work.
On the other hand, in the STL (Standard Template Library), virtually all of the code is in header files. (without the .h extension)
I am working on a small game using C++, and I used Eclipse CDT's class generator. It created a .h file with the class definitions and a .cpp file that included body-less methods for said class.
So if I followed the template, I'd have a .cpp file filled with the methods declarations, and a .cpp file with method bodies. However, I can't include a .cpp file within another.
So what is the convention in C++ with classes and include files? What I did was fill in the method bodies right under the class declaration in the .h file, and deleted the .cpp file.
You don't have to include the .cpp file. Including the .h file is all it takes. .h means header, ie, all it should have is function / object definitions. The actual implementations go in the .cpp file of the same name. The linker will deal with straightening it out for you.
The header file contains declarations (also known as prototype). Inclusion of the header lets the program know "I declare something that looks like this exists".
The user of headers saves us the effort of declaring methods all over the place in our code files - we just do it once, then import the file.
The .c/.cpp/.cc file includes the definition - which tells the program what the function does.
You do not have to "include" .c files because that's what the compiler does - it compiles all your .c files into machine code.
One more thing you can do is while creating a header file is to use the preprocessor directive
ifdef and endif. This will prevent your header file being included multiple times.
This is a standard practice which I use whenever I create a new header file.
I'm not quite sure I understand. The header files defines what the class is and can do, and you include that into any source files that need to use the class.
The source file implements how the class does its action.
However, you can include a .cpp into another (you can include anything into anything), but you don't need to.