As it currently stands, this question is not a good fit for our Q&A format. We expect answers to be supported by facts, references, or expertise, but this question will likely solicit debate, arguments, polling, or extended discussion. If you feel that this question can be improved and possibly reopened,
visit the help center for guidance.
Closed 6 years ago.
What are the advantages of using multiple source (.cpp) and header (.h) files in a single project?
Is it just a preferential thing or are there true benefits?
It helps you split your code and sort it by theme. Otherwise you get one file with 1000s of lines… which is hard to manage…
Usually, people have .h and .c for one or sometimes a few classes.
Also, it speeds up compilation, since only the modified files, and some related files need to be recompiled.
From Organizing Code Files in C and C++:
Splitting any reasonably-sized project up buys you some advantages,
the most significant of which are the following:
Speed up compilation - most compilers work on a file at a time. So if all your
10000 lines of code is in one file, and you change one line, then you
have to recompile 10000 lines of code. On the other hand, if your
10000 lines of code are spread evenly across 10 files, then changing
one line will only require 1000 lines of code to be recompiled. The
9000 lines in the other 9 files will not need recompiling. (Linking
time is unaffected.)
Increase organization - Splitting your code along logical lines will
make it easier for you (and any other programmers on the project) to
find functions, variables, struct/class declarations, and so on. Even
with the ability to jump directly to a given identifier that is
provided in many editors and development environments (such as
Microsoft Visual C++), there will always be times when you need to
scan the code manually to look for something. Just as splitting the
code up reduces the amount of code you need to recompile, it also
reduces the amount of code you need to read in order to find
something. Imagine that you need to find a fix you made to the sound
code a few weeks ago. If you have one large file called GAME.C,
that's potentially a lot of searching. If you have several small
files called GRAPHICS.C, MAINLOOP.C, SOUND.C, and INPUT.C, you know
where to look, cutting your browsing time by 3/4.
Facilitate code reuse - If your code is carefully split up into
sections that operate largely independently of each other, this lets
you use that code in another project, saving you a lot of rewriting
later. There is a lot more to writing reusable code than just using a
logical file organization, but without such an organization it is
very difficult to know which parts of the code work together and
which do not. Therefore putting subsystems and classes in a single
file or carefully delineated set of files will help you later if you
try to use that code in another project.
Share code between projects - The principle here is the same as with
the reuse issue. By carefully separating code into certain files, you
make it possible for multiple projects to use some of the same code
files without duplicating them. The benefit of sharing a code file
between projects rather than just using copy-and-paste is that any
bug fixes you make to that file or files from one project will affect
the other project, so both projects can be sure of using the most
up-to-date version.
Split coding responsibilities among programmers - For really large
projects, this is perhaps the main reason for separating code into
multiple files. It isn't practical for more than one person to be
making changes to a single file at any given time. Therefore you
would need to use multiple files so that each programmer can be
working on a separate part of the code without affecting the file
that the other programmers are editing. Of course, there still have
to be checks that 2 programmers don't try altering the same file;
configuration management systems and version control systems such as
CVS or MS SourceSafe help you here. All of the above can be
considered to be aspects of modularity, a key element of both
structured and object-oriented design.
Then, they go on about How to do it, Potential Pitfalls, Fixing problems, etc.
You should check it.
Code files become unmaintainable (try searching in them!) after a few hundred lines. Some people go up to a few thousand (but this is already a problem). Even small projects have thousands of lines, medium projects have tens of thousands of lines, and big projects have millions of lines. Text editors cannot cope with files this big (but programmers themselves cannot either).
Splitting a project into different source files is also necessary if you want to separate your project into different compilation units, which makes compilation much faster because only parts of the projects need to be recompiled.
A few decades ago programs used to be written in one single file / stack of cards. However, these programs were tiny in comparison to modern programs, and completely unmaintainable – even small changes essentially necessitated a rewrite, which put a fixed upper limit on the complexity that could thus be achieved.
Modern, more complex projects essentially require splitting apart. The question of putting everything in one file is frankly one that I’ve never asked myself because the idea is simply inconceivable.
Different cpp files are compiled as separate compilation units. This allows you to isolate things (header inclusions, anonymous namespaces, pimpl) from the rest of the source code.
Sometimes two libraries can not be used together in one source file because they have name clashes. This can be solved by including each library header in a different cpp file and expose required functionality via corresponding header files.
if its a small project such as hello world, there is no advantage, but imagine something like windows, or google chrome, or android.
a project of that size could not possibly be managed with a single file.
multiple files for your project are about manageability and re usability for the code.
