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

Question

I was wondering which are the differences between declaring and implementing a class solely in a header file, compared with normal approach in which you protype class in the header and implement in effective .cpp file.

To explain better what I'm talking about I mean differences between normal approach:

// File class.h class MyClass  { private:   //attributes   public:   void method1(...);   void method2(...);   ... };  //file class.cpp #include "class.h"  void MyClass::method1(...)  {   //implementation }  void MyClass::method2(...)  {   //implementation } 

and a just-header approach:

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

I can get the main difference: in the second case the code is included in every other file that needs it generating more instances of the same implementations, so an implicit redundancy; while in the first case code is compiled by itself and then every call referred to object of MyClass are linked to the implementation in class.cpp.

But are there other differences? Is it more convenient to use an approach instead of another depending on the situation? I've also read somewhere that defining the body of a method directly into a header file is an implicit request to the compiler to inline that method, is it true?

Answer 1

Any change to a header that includes the implementation will force all other classes that include that header to recompile and relink.

Since headers change less frequently than implementations, by putting the implementation in a separate file, you can save considerable compilation time.

As some other answers have already pointed out, yes, defining a method within a file's class block will cause the compiler to inline.

Answer 2

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.