Differencebetween a .Cpp File and a .H File

What is the difference between a .cpp file and a .h file?

The C++ build system (compiler) knows no difference, so it's all one of conventions.

The convention is that .h files are declarations, and .cpp files are definitions.

That's why .h files are #included -- we include the declarations.

What's the REAL difference between .h and .cpp files?

Practically: the conventions around .h files are in place so that you can safely include that file in multiple other files in your project. Header files are designed to be shared, while code files are not.

Let's take your example of defining functions or variables. Suppose your header file contains the following line:

header.h:

int x = 10;

code.cpp:

#include "header.h"

Now, if you only have one code file and one header file this probably works just fine:

g++ code.cpp -o outputFile

However, if you have two code files this breaks:

header.h:

int x = 10;

code1.cpp:

#include "header.h"

code2.cpp:

#include "header.h"

And then:

g++ code1.cpp -c  (produces code1.o)
g++ code2.cpp -c  (produces code2.o)
g++ code1.o code2.o -o outputFile

This breaks, specifically at the linker step, because now you have two symbols in the same executable that have the same symbol, and the linker doesn't know what's it's supposed to do with that. When you include your header in code1 you get a symbol "x" and when you include your header in code2 you get another symbol "x". The linker doesn't know your intention here, so it throws an error:

code2.o:(.data+0x0): multiple definition of `x'
code1.o:(.data+0x0): first defined here
collect2: error: ld returned 1 exit status

Which again is just the linker saying that it can't resolve the fact that you now have two symbols with the same name in the same executable.

What's the difference between including a header and a C++ 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.

What is the difference between including a .c file and a .h file

It depends on what is in the file(s).

The #include preprocessor directive simply inserts the referenced file at that point in the original file.

So what the actual compiler stage (which runs after the preprocessor) sees is the result of all that inserting.

Header files are generally designed and intended to be used via #include. Source files are not, but it sometimes makes sense. For instance when you have a C file containing just a definition and an initializer:

const uint8_t image[] = { 128, 128, 0, 0, 0, 0, ... lots more ... };

Then it makes sense to make this available to some piece of code by using #include. It's a C file since it actually defines (not just declares) a variable. Perhaps it's kept in its own file since the image is converted into C source from some other (image) format used for editing.

What is the difference between a .h(header file) and a .cpp file?

There are two considerations here. First off, header files are not nearly as important in managed code as they are in native C or C++. Managed code compilers read declarations from the assembly metadata, you don't (and shouldn't) write C++/CLI type declarations that need to be visible in other modules in header files. Getting them from the metadata makes your types available to any .NET language.

But the real reason is because of the way the form designer works in the C++ IDE. It is a code generator, driven by the controls you drop on a form or user control and the properties you set in the Properties window. There is a very awkward problem if that code generator needs to generate code in two separate files. Not so much the generating bit, but removing code when you alter the design of the form. Getting the files out of sync produces difficult to diagnose compile errors from auto-generated code. It is a lot more likely to happen than you might think btw, the code generator needs to work with source code files that are in the process of being edited. Very difficult, the code might not parse at all.

The C++ IDE uses the original approach taken by the version 1.1 C# and VB.NET designers, everything goes in one file. Which is unpleasant of course, declarations and code shouldn't be mixed. That was solved in those designers for version 2.0 by adding support to the C# and VB.NET languages for partial classes. That however didn't happen for C++/CLI. Not sure why, the C++/CLI team always looked resource constrained compared to those other teams. It also doesn't have any kind of refactoring support, which is very important to rename methods when the class name changes. Keeping the methods inline avoids the problem.

Anyhoo, you can get your code in the .cpp file but you have to do it yourself. Cut+paste gets it done, but you'll also have to edit the class name back into the method declarations. This is high maintenance, consider if it is worth the effort. Also consider whether you really want to use C++/CLI for the UI, it is an uncommon choice.

Difference between .h, .hpp, .cpp files in PCL

Consider that only the .h is the header file, the one that contains the definitions and the one you should include.

The implementations are in both the hpp and the cpp files.

• hpp: contains the generic templates template<class T>,
• cpp: contains non template functions or explicit instantiations template<pcl::PointXYZ>

Both files .h and .hpp can be merged in same file but is clearer to separate them.

Difference in including the .cpp file and .h file (with the same content in cpp)?

what difference it makes?

The extension of a header file has no effect on anything. You could have just as well named the file test.mpg, .test or just test (changing the include directive obviously), and it would have worked just as well. The extension is for the benefit of the programmer, not the toolchain.

However, it is a bad idea to name it anything other than .h, .hpp or whatever is your convention. If you name it .mpg, people will think that it is a video, and not realising that it is a header file, try to play it in a media player. If you name it .cpp, people will think that it is a source file and may attempt to compile it or maybe add definitions into it.

Including a file with the preprocessor is technically just copying contents of one file into another. Nothing more and nothing less. Everything else about them is just convention.

In makefile, when specifying source file, Can I give my source files with any extension(.fsfs, .xxx) rather than .cpp extension

Technically yes, however compilers usually use the source file extension to detect the language which they will fail to do in this case, so you would have to specify it explicitly.

Difference between implementing a class inside a .h file or in a .cpp file

The main practical difference is that if the member function definitions are in the body of the header, then of course they are compiled once for each translation unit which includes that header. When your project contains a few hundred or thousand source files, and the class in question is fairly widely used, this might mean a lot of repetition. Even if each class is only used by 2 or 3 others, the more code in the header, the more work to do.

If the member function definitions are in a translation unit (.cpp file) of their own, then they are compiled once, and only the function declarations are compiled multiple times.

It's true that member functions defined (not just declared) in the class definition are implicitly inline. But inline doesn't mean what people might reasonably guess it means. inline says that it's legal for multiple definitions of the function to appear in different translation units, and later be linked together. This is necessary if the class is in a header file that different source files are going to use, so the language tries to be helpful.

inline is also a hint to the compiler that the function could usefully be inlined, but despite the name, that's optional. The more sophisticated your compiler is, the better it is able to make its own decisions about inlining, and the less need it has for hints. More important than the actual inline tag is whether the function is available to the compiler at all. If the function is defined in a different translation unit, then it isn't available when the call to it is compiled, and so if anything is going to inline the call then it's going to have to be the linker, not the compiler.

You might be able to see the differences better by considering a third possible way of doing it:

// File class.h
class MyClass
{
    private:
        //attributes
    public:
       void method1(...);
       void method2(...);
       ...
};

inline void MyClass::method1(...)
{
     //implementation
}

inline void MyClass::method2(...)
{
     //implementation
}

Now that the implicit inline is out of the way, there remain some differences between this "all header" approach, and the "header plus source" approach. How you divide your code among translation units has consequences for what happens as it's built.

what is the difference between header and source files C++?

When you include a header file it will be inlined at compile time, meaning it probably has to have C++ content in it (unless the entire file be comments). From this point of view, .h and .cpp files are the same in that they both contain C++ code.

However, best practices dictate that .h files be used for templating and class definitions, while .cpp files are used for implementations and source code. It is bad practice to mix usage of the two although it is possible.

---

Related Topics