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

Question

I am creating a windows:forms application. I have read some of the answers give to try to understand the concept of .h(header file) & .cpp(implementation files). As I created the GUI for my app. I noticed the code being placed in the .h file. But when I double clicked a button control to add code to the procedure, the code was created in the .h file instead of the .cpp file. Do I cut and place this code into the .cpp file or is this where linking come in? The procedure deffintion stays in the .h file and will be linked to the procedure code in the .cpp file.

Answer 1

Function prototypes (you called them procedure definitions) should go in the header file (along with macros). Any code should go in the .cpp file.

If you're sure that what you're thinking of moving is code, it should be moved there. It would help to paste some code.

Answer 2

The header (*.h) files are suppose to contain definitions of your classes, methods and types while the cpp files suppose to have the implementation details. It is common to have inline and short methods in the header files as well.

This practice is not enforced by the compiler so you can write implementation (i.e. code) inside the header file.

Answer 3

As others have stated the header file is meant for class, function, type etc. declarations while the .cpp file should contain the implementations of the functions. However, a compiler does not care where the implementation code is written so you can put all your code in the header itself. But doing so will increase the compilation time because all that code will be compiled in every file that you include that header file in.

Keeping the implementation separate is very useful if you want to distribute your code but need to keep proprietary code hidden. In this case you can create a library from the implementation code and distribute the header along with the library.

The exception to this is when writing template code; in that case the implementation must go into the header because the compiler needs to 'see' it at the callsite.

Answer 4

Personally I'm moving that automatically generated code to *.cpp files. In *.h files I'm leaving functions which are not going to be changed very often. I'm doing that to be sure that compilation times will not grow to much after every change I made.

Answer 5

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.