Is it a good practice to place C definitions in header files

Question

My personal style with C   has always to put class declarations in an include file  and definitions in a  cpp file  very much like stipulated in Loki s answer to C   Header Files  Code Separation  Admittedly  part of the reason I like this style probably has to do with all the years I spent coding Modula-2 and Ada  both of which have a similar scheme with specification files and body files   I have a coworker  much more knowledgeable in C   than I  who is insisting that all C   declarations should  where possible  include the definitions right there in the header file  He s not saying this is a valid alternate style  or even a slightly better style  but rather this is the new universally-accepted style that everyone is now using for C     I m not as limber as I used to be  so I m not really anxious to scrabble up onto this bandwagon of his until I see a few more people up there with him  So how common is this idiom really    Just to give some structure to the answers  Is it now The Way  very common  somewhat common  uncommon  or bug-out crazy

User · Answer

I think your co-worker is smart and you are also correct.

The useful things I found that putting everything into the headers is that:

No need for writing & sync headers and sources.
The structure is plain and no circular dependencies force the coder to make a "better" structure.
Portable, easy to embedded to a new project.

I do agree with the compiling time problem, but I think we should notice that:

The change of source file are very likely to change the header files which leads to the whole project be recompiled again.
Compiling speed is much faster than before. And if you have a project to be built with a long time and high frequency, it may indicates that your project design has flaws. Seperate the tasks into different projects and module can avoid this problem.

Lastly I just wanna support your co-worker, just in my personal view.

User · Answer

If this new way is really The Way  we might have been running into different direction in our projects   Because we try to avoid all unnecessary things in headers  That includes avoiding header cascade  Code in headers will propably need some other header to be included  which will need another header and so on  If we are forced to use templates  we try avoid littering headers with template stuff too much   Also we use  opaque pointer -pattern when applicable    With these practices we can do faster builds than most of our peers  And yes    changing code or class members will not cause huge rebuilds

User · Answer

I think that it s absolutely absurd to put ALL of your function definitions into the header file  Why  Because the header file is used as the PUBLIC interface to your class  It s the outside of the  black box    When you need to look at a class to reference how to use it  you should look at the header file  The header file should give a list of what it can do  commented to describe the details of how to use each function   and it should include a list of the member variables  It SHOULD NOT include HOW each individual function is implemented  because that s a boat load of unnecessary information and only  clutters the header file

User · Answer

Your coworker is wrong  the common way is and always has been to put code in  cpp files  or whatever extension you like  and declarations in headers   There is occasionally some merit to putting code in the header  this can allow more clever inlining by the compiler  But at the same time  it can destroy your compile times since all code has to be processed every time it is included by the compiler   Finally  it is often annoying to have circular object relationships  sometimes desired  when all the code is the headers   Bottom line  you were right  he is wrong   EDIT  I have been thinking about your question  There is one case where what he says is true  templates  Many newer  modern  libraries such as boost make heavy use of templates and often are  header only   However  this should only be done when dealing with templates as it is the only way to do it when dealing with them   EDIT  Some people would like a little more clarification  here s some thoughts on the downsides to writing  header only  code   If you search around  you will see quite a lot of people trying to find a way to reduce compile times when dealing with boost  For example  How to reduce compilation times with Boost Asio  which is seeing a 14s compile of a single 1K file with boost included  14s may not seem to be  exploding   but it is certainly a lot longer than typical and can add up quite quickly  When dealing with a large project  Header only libraries do affect compile times in a quite measurable way  We just tolerate it because boost is so useful   Additionally  there are many things which cannot be done in headers only  even boost has libraries you need to link to for certain parts such as threads  filesystem  etc   A Primary example is that you cannot have simple global objects in header only libs  unless you resort to the abomination that is a singleton  as you will run into multiple definition errors  NOTE  C  17 s inline variables will make this particular example doable in the future   As a final point  when using boost as an example of header only code  a huge detail often gets missed   Boost is library  not user level code  so it doesn t change that often  In user code  if you put everything in headers  every little change will cause you to have to recompile the entire project  That s a monumental waste of time  and is not the case for libraries that don t change from compile to compile   When you split things between header source and better yet  use forward declarations to reduce includes  you can save hours of recompiling when added up across a day

User · Answer

To add more fun you can add  ipp files which contain the template implementation  that is being included in  hpp   while  hpp contains the interface   As apart from templatized code  depending on the project this can be majority or minority of files  there is normal code and here it is better to separate the declarations and definitions  Provide also forward-declarations where needed - this may have effect on the compilation time

User · Answer

I think your co-worker is right as long as he does not enter in  the process to write executable code in the header  The right balance  I think  is to follow the path indicated by GNAT Ada where the  ads file gives a perfectly adequate interface definition of the package for its users and for its childs   By the way Ted  have you had a look on this forum to the recent question on the Ada binding to the CLIPS library you wrote several years ago and which is no more available  relevant Web pages are now closed   Even if made to an old Clips version  this binding could be a good start example for somebody willing to use the CLIPS inference engine within an Ada 2012 program

User · Answer

Code in headers is generally a bad idea since it forces recompilation of all files that includes the header when you change the actual code rather than the declarations  It will also slow down compilation since you ll need to parse the code in every file that includes the header   A reason to have code in header files is that it s generally needed for the keyword inline to work properly and when using templates that s being instanced in other cpp files

User · Answer

I personally do this in my header files      class-declaration     inline-method-declarations   I don t like mixing the code for the methods in with the class as I find it a pain to look things up quickly   I would not put ALL of the methods in the header file   The compiler will  normally  not be able to inline virtual methods and will  likely  only inline small methods without loops  totally depends on the compiler    Doing the methods in the class is valid    but from a readablilty point of view I don t like it   Putting the methods in the header does mean that  when possible  they will get inlined

User · Answer

Often I ll put trivial member functions into the header file  to allow them to be inlined  But to put the entire body of code there  just to be consistent with templates  That s plain nuts   Remember  A foolish consistency is the hobgoblin of little minds

User · Answer

Generally  when writing a new class  I will put all the code in the class  so I don t have to look in another file for it     After everything is working  I break the body of the methods out into the cpp file  leaving the prototypes in the hpp file

User · Answer

The day C   coders agree on The Way  lambs will lie down with lions  Palestinians will embrace Israelis  and cats and dogs will be allowed to marry   The separation between  h and  cpp files is mostly arbitrary at this point  a vestige of compiler optimizations long past  To my eye  declarations belong in the header and definitions belong in the implementation file  But  that s just habit  not religion

User · Answer

IMHO  He has merit ONLY if he s doing templates and or metaprogramming   There s plenty of reasons already mentioned that you limit header files to just declarations   They re just that    headers   If you want to include code  you compile it as a library and link it up

User · Answer

As Tuomas said  your header should be minimal  To be complete I will expand a bit   I personally use 4 types of files in my C   projects    Public  Forwarding header  in case of templates etc  this file get the forwarding declarations that will appear in the header  Header  this file includes the forwarding header  if any  and declare everything that I wish to be public  and defines the classes     Private  Private header  this file is a header reserved for implementation  it includes the header and declares the helper functions   structures  for Pimpl for example or predicates   Skip if unnecessary  Source file  it includes the private header  or header if no private header  and defines everything  non-template       Furthermore  I couple this with another rule  Do not define what you can forward declare  Though of course I am reasonable there  using Pimpl everywhere is quite a hassle    It means that I prefer a forward declaration over an  include directive in my headers whenever I can get away with them   Finally  I also use a visibility rule  I limit the scopes of my symbols as much as possible so that they do not pollute the outer scopes   Putting it altogether      example fwd hpp    Here necessary to forward declare the template class     you don t want people to declare them in case you wish to add    another template symbol  with a default  later on class MyClass  template  lt class T gt  class MyClassT      example hpp  include  project example fwd hpp      Those can t really be skipped  include  lt string gt   include  lt vector gt    include  project pimpl hpp      Those can be forward declared easily  include  project foo fwd hpp   namespace project   class Bar     namespace project     class MyClass       public      struct Color    Limiting scope of enum             enum type   Red  Orange  Green               typedef Color  type Color t     public      MyClass       because of pimpl  I need to define the constructor    private      struct Impl      pimpl lt Impl gt  mImpl     I won t describe pimpl here  p         template  lt class T gt  class MyClassT  public MyClass          namespace project     example impl hpp  not visible to clients   include  project example hpp   include  project bar hpp   template  lt class T gt  void check MyClass lt T gt  const amp  c          example cpp  include  example impl hpp      MyClass definition   The lifesaver here is that most of the times the forward header is useless  only necessary in case of typedef or template and so is the implementation header

User · Answer

Doesn t that really depends on the complexity of the system  and the in-house conventions   At the moment I am working on a neural network simulator that is incredibly complex  and the accepted style that I am expected to use is   Class definitions in classname h   Class code in classnameCode h   executable code in classname cpp  This splits up the user-built simulations from the developer-built base classes  and works best in the situation   However  I d be surprised to see people do this in  say  a graphics application  or any other application that s purpose is not to provide users with a code base

User · Answer

What might be informing you coworker is a notion that most C   code should be templated to allow for maximum usability   And if it s templated  then everything will need to be in a header file  so that client code can see it and instantiate it   If it s good enough for Boost and the STL  it s good enough for us   I don t agree with this point of view  but it may be where it s coming from

User · Answer

I put all the implementation out of the class definition  I want to have the doxygen comments out of the class definition

User · Answer

Template code should be in headers only  Apart from that all definitions except inlines should be in  cpp  The best argument for this would be the std library implementations which follow the same rule  You would not disagree the std lib developers would be right regarding this

[c++] Is it a good practice to place C++ definitions in header files?

Examples related to c++

Examples related to coding-style

Examples related to code-separation