2

When is it necessary to separately declare a class in a ”.h” file and provide the function implementations in a ”.cpp” file?

Athru.K
  • 51
  • 1
  • 1
    Historical reasons, from when programmer time was cheaper than machine time, so you'd give the compiler the `.h` to know what to expect and do its checks. For the sake of compatibility with the stone age of programming, this is still in use today. – Robert Nov 13 '16 at 03:04
  • 2
    @Robert It's used extensively to reduce compilation times, not just for the "sake of compatibility with the stone age of programming". Compilation times could be annoying. – ABu Nov 13 '16 at 03:28
  • @Peregring-lk If you keep the object files, you still reduce compile times. The compiler could just look at the `.cpp` instead of the `.h`. That way the programmer would not be forced to duplicate all the information between `.h` and `.cpp` file. – Robert Nov 13 '16 at 23:05
  • @Robert I didn't understood you. If you modify a function member definition, and it is in a `.cpp` hidden from other files, you have to recompile and link just that `.cpp` instead of all dependent files. – ABu Nov 14 '16 at 00:56

5 Answers5

2

It is not strictly necessary, as far as the C++ language is concerned. You can put all class methods inline in the .h file.

However, putting the implementations into a separate .cpp offers many benefits, such as:

  1. C++ is very complex. As the code grows, it will take longer and longer to compile it. Every .cpp file that includes the same header file will end up compiling the same code, over and over again.

  2. Related to the first point: if any change is made to the class's methods, if all the class methods are in a separate .cpp file, only that .cpp needs recompilation. If all class methods are placed inline into the .h file, every .cpp that includes will must be recompiled.

  3. Very often, the class's methods will use other classes as part of doing whatever they need to do. So, if they're all placed inline in the .h file, the .h file that defines those other classes will need to be included also, also slowing down the compilation of every .cpp file that includes the header file. If the class methods are in a separate .cpp file, only that .cpp file needs to include the other headers, and most of the time it's only necessary to add some forward declarations to the .h.

Sam Varshavchik
  • 114,536
  • 5
  • 94
  • 148
  • To be more specific about why the time difference is so big, you could add that function declarations doesn't generate machine code, just type checking when calling it. Class are a bit more complex, but for member functions the same logic applies. Also, don't offering function definitions to the compiler, avoids the compiler looks into it (from a calling point) in search of optimizations. – ABu Nov 13 '16 at 03:34
1

It's done that way so that you only build the class' code one time. If you put the class' code in the .h file, then every file that picks up the .h (to access the public functions of the class) will also duplicate the class' code. The compiler will happily do this for you. The linker, however, will complain mightily about duplicate lvalues in the namespace.

Along the same lines, yet conversely: inline functions need to be in the .h so that their code will get picked up in the other code files, which is exactly the intent of inline functions.

Der Schley
  • 466
  • 4
  • 6
1

If you want to use declarations to implement/define the function, declarations that you don't want to make visible in the *.h file, then it would be necessary to move the definition of the function to a separate file.

Waxrat
  • 2,075
  • 15
  • 13
0

Usually that's a good separation between class definition (.h) and class implementation (.cpp) People can just read the .h files to know and use the class without bothering reading the implementation details.

It's, however, not mandatory to always separate .h and .cpp, you can have the class definition and implementation in a single file (eg., for some simple classes, or some quick prototypes).

artm
  • 17,291
  • 6
  • 38
  • 54
  • I'd even disagree that header files are good for hiding implementation details, since you'll see all the private class members in the header file. – Robert Nov 13 '16 at 23:23
  • @Robert true, if you look at the header files, you know more than you would need know about implementation (ie the private members). I did not mention information hiding. I only mentioned that it's more convenient to look at the class header to **use** it. – artm Nov 14 '16 at 00:10
0

From a technical perspective (in terms of what a compiler needs or will accept) it is almost never necessary - it is possible to copy/paste the content of every (non-standard) header file into the source files that include them, and compile that. After all, that is effectively what the preprocessor does with #include directives - copy the included file in place, after which the resultant source is fed to later phases of the compiler.

It is possible for a compiler to run out of memory when compiling source - in which case breaking the program into smaller pieces, including header files, can help - but such circumstances (on machines with very limited hardware resources, such as memory) are very rare in modern development.

However, humans are less consistent and more error prone than compilers when dealing with source files, so humans benefit from use of header files. For example, instead of typing (or copying in) needed declarations into every source file that needs them (an activity which people find boring, and tend to make mistakes when doing) simply place the declarations in a header file and #include it when needed.

So then it comes down to when placing declarations in a header file makes life easier for a human, allowing them to avoid making errors, and to focus their effort on the creative parts of software development (implementing new things) rather than the mechanical (copying function declarations into source files that need them).

In practice, it normally works out that a class which will be used within more than one compilation unit (aka source file) is better off being defined in a header file. A class which is local to a single compilation unit (e.g. to contain implementation details for that compilation unit that do not need to be directly accessed by others) does not need to be in a header file, since it can be defined directly without use of a header. The problems come in if such "local" classes later need to be used in other compilation units - in that case, it is usually advisable to migrate the necessary declarations to a header file, to aid reuse.

Header files also tend to become necessary for authors of libraries - who write a set of functions for use by other programmers, but don't wish to ship the source. This is a non-technical constraint (i.e. policy based), rather than a technical one. In that case, they can distribute the header files and the compiled object (or library) files, and keep their source code private. Of course, technically, they could provide a set of text files with instructions of the form "copy these declarations to your program when you need to use them" instead of header files ..... but that would make the library unpopular with developers, since it forces them back into the mundane and error-prone activity of copying text around rather than doing useful development.

Considerations like reducing compile times are also non-technical reasons (a compiler doesn't care how long it takes to build a program, but people do). Separating class definitions into header (class definition, any inline functions) and separate source (definition of non-inline member functions) does tend to reduce build times, and aid with incremental builds.

Peter
  • 35,646
  • 4
  • 32
  • 74