Why Separate MyClass.h and MyClass.cpp Files?

[adaptation]

I understand the concept of creating a new header file for a class (something like MyClass.h), but what's the point of creating a MyClass.cpp? http://www.codeblocks.org/" creates both files for me when I add a new class to my project. I'm sure there's a good reason, I just don't know it

In the past, I've only ever used *.h files to define classes. I've always put main() in my main.cpp. I've never had a reason to have more than one *.cpp file in a project. I'm kind of stumped. Is there a principal of OOP that I'm totally overlooking (I'm sure there is/are)?

Thanks in advance for your help.

 

[jtbell]

MyClass.h normally contains only the information necessary for the main program to "interface" with MyClass, that is, the class declaration and prototypes for the member functions. MyClass.cpp contains the "guts" of the member functions, that is, the C++ statements that spell out exactly how the member functions "do their thing."

Having the two files MyClass.h and MyClass.cpp allows you to compile MyClass only once, and thereafter simply link it to any program that uses it. (assuming you don't change MyClass in the meantime, which requires re-compiling it and often, re-linking it to all programs that use it)

When compiling MyClass by itself, you use MyClass.h and MyClass.cpp, and get a compiled object-code or library file which might be called MyClass.o or MyClass.a or something else.

When compiling a program MyProg.cpp that uses MyClass, you use MyProg.cpp and MyClass.h to produce an object file which might be called MyProg.o. Then you link MyProg.o with MyClass.o to produce an executable program which might be called simply MyProg.

For small classroom-type programs, it's often hard to see the benefit of this method because of the extra steps involved in compiling MyClass separately and linking it with MyProg, compared to putting everything in a single source-code file and compiling it in one shot.

The benefits really come when you write classes that will be used by many different programs, and/or the classes are big enough that they take a long time to compile.

 

[TylerH]

Putting definitions (the actual code) in the .h and then including the .h in multiple .cpps will cause a multiple definition error during the linking stage. This happens because the compiler includes the definition to those functions in each object it compiles from files that include the .h. Then, when the linker gets all those objects that are all defining the same symbol, it doesn't know which to use, so it throws an error.

 

[adaptation]

MyClass.h normally contains only the information necessary for the main program to "interface" with MyClass, that is, the class declaration and prototypes for the member functions. MyClass.cpp contains the "guts" of the member functions, that is, the C++ statements that spell out exactly how the member functions "do their thing."

Thank you! Very clear explanation. I had a total "oooooh!" moment after reading this.

In the past I had always put member definitions at the end of the class declaration. I like the MyClass.h and Myclass.cpp approach better. I'll definitely be adopting it.

For small classroom-type programs, it's often hard to see the benefit of this method because of the extra steps involved in compiling MyClass separately and linking it with MyProg, compared to putting everything in a single source-code file and compiling it in one shot.

This is my main problem. I've never really coded anything that large. The longest thing I did was a raytracer. In its simplest form a raytracer can be written in a couple dozen lines. (Maybe less?)

The benefits really come when you write classes that will be used by many different programs, and/or the classes are big enough that they take a long time to compile.

And this is exactly what I want to do. I suppose I should read up on coding libraries.

Putting definitions (the actual code) in the .h and then including the .h in multiple .cpps will cause a multiple definition error during the linking stage. This happens because the compiler includes the definition to those functions in each object it compiles from files that include the .h. Then, when the linker gets all those objects that are all defining the same symbol, it doesn't know which to use, so it throws an error.

Yeah. Another one of my problems, I've never even tried this. Comes from my lack of experience with larger projects.

Thanks a lot guys. I think I've got it.

 

[jtbell]

Also, when you write classes that other people are going to use in their programs, they normally work with the .h file that they #include in their programs, and a compiled .o file (or whatever) that they link to their compiled code. You might actually give them the source code, but they'll compile it first, and install the .o or .a file in a library directory somewhere.

This is the way all the C++ standard library stuff works, for example. When you #include <string>, you're not re-compiling the string member functions every time you compile a program, you just link to the corresponding compiled code somewhere in a big library file that all C++ programs use by default.

 

[rcgldr]

This is the way all the C++ standard library stuff works

One exception is the Standard Template Library, which does include code, but it's used to declare instances of classes, not to set definitions for classes.

 

[Hurkyl]

For the record, any inline functions should be defined in the header file. (if they're globals and not member functions, you probably need to make them static inline)

If you don't do it that way, then in any other compilation unit, you cannot get any of the benefit of inlining.

(template functions are similarly required to be defined in the header file, unless you have a fancy compiler that allows other variations)