1

I have a big .cpp file with several classes defined and declared in one single file. I was thinking of having a .h file for each class but I am not sure about the advantages.

Is splitting your files pure preference? Would this increase compile time AND/OR general readibility? My compiler gives me a list of all class declarations that I can easily access with one click, hence if the compiler needs more time putting all those files together, I rather keep it in one chunk.

Edit: I am asking splitting into .cpp and .h and not multiple cpp's as this question has been dismissed that there is already an answer.

Majte
  • 264
  • 2
  • 9
  • They're all stuck in one big file by the prepocessor if it's just one big .cpp and several headers – daniel gratzer Nov 05 '13 at 15:29
  • Splitting your mega file into smaller files means that when you change 1 thing in one of the smaller files, only the files that directly depend on those files (as well as that one changed file) must be recompiled. So for the most part, yes, it will decrease compile time unless you are changing a file that every other file depends on. – zero298 Nov 05 '13 at 15:31
  • oh I didn't know.. that would make then perfectly sense! – Majte Nov 05 '13 at 15:32
  • possible duplicate of [Will splitting code into several .cpps decrease compilation time?](http://stackoverflow.com/questions/1501446/will-splitting-code-into-several-cpps-decrease-compilation-time) – Mike D Nov 05 '13 at 15:34
  • 2
    One other thing to go along with that though, most IDEs are automatically configured to know what files depend on other files. However, if you are building from the command line using g++, if you just tell it to compile en masse your project, it will still be compiling everything every time. The solution to this is to understand and use proper Makefiles. – zero298 Nov 05 '13 at 15:34

2 Answers2

2

Having multiple files will not directly decrease the time, however as compilation can be carried out differentially, where only changed code is re-compiled to object files before linking means that if you have each set of classes in their own .cpp and .h files you can potentially save a lot of time. It also has corollary effects such as:

  • debugging is more straight-forward: you have a smaller file to work through to locate and correct any bugs and errors.
  • code will be clearer and more maintainable generally
  • if utilising makefiles you can selectively compile files to achieve a time saving
  • easier to re-use code: you can take any given part of your code over to a new project without inheriting all the parts you do not want/need
  • easier to document each class independently
  • easier to control revisions/more suited to source control
  • easier and more efficient to deploy code updates, rather than sending a whole new mega-file with 20 classes you can send just the ones which have changed.

This is by no means an exhaustive list, just a brief introduction really, and there can be almost as many arguments against it as for, but in general the pros outweigh the cons for me.

GMasucci
  • 2,834
  • 22
  • 42
0

The advantage of having many .h files is also that from some other translation units you might need to include only some of the interfaces, and not all of them (which you are forced to do if you have only one header file).

Instead, you probably want to keep in the each same header file any possible "helper" class that go together with the specific class that header is dedicated to.

Dario Digiuni
  • 31
  • 2