0

Possible Duplicate:
In C++ why have header files and cpp files?
C++ - What should go into an .h file?

All the functions/methods which are usually defined in .cpp file can be defined inline in .h file. So what is the reason for using .cpp at all? Effectivity? Compilation time?

Are there some standards as what can be kept in .h and what should go to .cpp?

Thank you.

Community
  • 1
  • 1
  • defining the functions in cpp hides the implementation. Also, the implementation may require services from other objects and classes. Adding such code in header puts a dependency on the code consuming the class that is being declared. – Ram Sep 20 '12 at 12:34
  • What does "effectivity" mean in your sentence? All code is either effective or dead, independent of how it's structured into files. – Kerrek SB Sep 20 '12 at 12:34
  • you can find many discussions on this topic. for example look at : [In C++ why have header files and cpp files? [closed]][1] [1]: http://stackoverflow.com/questions/333889/in-c-why-have-header-files-and-cpp-files – meirrav Sep 20 '12 at 12:34
  • I've been wondering the opposite. What if all classes were defined inline in .cpp files and the only thing in headers were pure virtual classes declaraions, and some factories? How would that look? – Peter Wood Sep 20 '12 at 13:24

3 Answers3

3

related to

This question and that

well basically the compiler is able to compile all files, regardless you put all the code in .h or .cpp files. Separating between them has fundamental pros

  1. In short u want to separate interface from implementation for visibility and reusability.
  2. It reduces compile time
  3. When you are using header files of a 3dparty library you really don´t care about it´s implementation but on function signatures to call
  4. When you offer your own library as an util library, you want to offer only the header files for the people to use, and the source library for people who want to develop your library This list can go further, but that´s whats come to my mind right now
Community
  • 1
  • 1
Moataz Elmasry
  • 2,509
  • 4
  • 27
  • 37
2
  • Reduce compile times. If the definitions were all in header files, everytime that header file changed, it would necessitate a compile for all files that included that header file.
  • Hide interface from implementation. Allows one to ship the headers and libraries.
sashang
  • 11,704
  • 6
  • 44
  • 58
2

You can't inline everything. Objects may be defined once and only once. Only classes and templates can be defined multiple times, and inlining only allows redefinition of functions.

For example, consider header.hpp:

extern int a;

struct Foo { static int b; };

The following must go into a dedicated, single translation unit:

#include "header.hpp"

int a;
int Foo::b;

On the other hand, static members of class templates can and must indeed stay in the header:

template <typename T> struct Foo { static int x; };
template <typename T> int Foo<T>::x;

The linker has to figure out how to uniquify the object.

Kerrek SB
  • 464,522
  • 92
  • 875
  • 1,084
  • I´d like to point out that global variables are a really bad idea – Moataz Elmasry Sep 20 '12 at 12:39
  • @MoatazElmasry: Remember that next time you use `std::cout`! – Kerrek SB Sep 20 '12 at 12:39
  • well cout is an operator function defined inside a namespace and not the same like "extern int a". besides std:: is simply a well established concept and not to be compared to user defined variables – Moataz Elmasry Sep 20 '12 at 12:41
  • @MoatazElmasry - What if Kerrek had used `class` rather that `struct` (or had explicitly marked that static class member as `private`)? There are plenty of places where a static member is exactly what is needed, and except for static members of integral type, those static members must have a definition in a source file. – David Hammen Sep 20 '12 at 13:17
  • @MoatazElmasry No, really, if you're using `std::cout`, extract a function using 'std::ostream&' instead. You can test it and reuse it far more easily. – Peter Wood Sep 20 '12 at 13:19
  • @David Hammen: of course, my objection is not to the static member, but to "extern int a", which is a global variable that doesn´t belong to a name space. my point is: there´s little/no need for such variables, or maybe I´m mistaken – Moataz Elmasry Sep 20 '12 at 13:40
  • 2
    @MoatazElmasry: #1, you're mistaken. A blanket ban against globals would rule out almost all I/O devices, would rule out using memory mapped I/O, would rule out a lot of very things where a global variable is the best design decision. Globals are not necessarily evil. Can they be abused? Surely. Most uses probably are abuses. That does not mean they are always bad, or that you can always find an alternative. #2, You missed Kerrek's point with this off-topic rant against globals. His point was that you cannot put everything in a header. Sometimes a source file is absolutely necessary. – David Hammen Sep 20 '12 at 14:14