Re: About #include statements and other related questions

Vicent Giner-Bosch wrote:


  Assume your program consisted of about 100000 lines of code, which
nowadays would be considered a medium-sized project (and I'm sure that
in many parts of the professional programming industry it would
actually be considered on the smaller end of medium-sized
projects). Now assume that all those lines were in one single file.

  Editing that file would probably become a nightmare. Also compiling
100 thousand lines of code will probably take even the fastest
compilers several minutes, and you would have to do that every single
time you make any change to the file and want to compile&run it. Just
imagine that you are making and testing small changes, such as
changing one single number in your program, and then having to wait
several minutes for the thing to compile, then you fine-tune that
number again and again wait for several minutes for it to compile. You
probably see why this wouldn't be such a great idea.

  A program is best divided into logical independent parts in such way
that you can change one part without having to touch the rest, which
not only makes compiling a lot faster (because only the modified part
has to be compiled, not everything), but also makes the program a
whole lot more manageable and maintainable. When such independent
parts are well designed, it also makes them reusable so that you can
take those files and use them in a different program as-they-are (thus
you ended up creating a so-called library).

  I hope you start to see why it's a good idea to divide your program
into logical parts, rather than keeping everything in one single file.

  Of course the problem is that the different parts need to interact
with each other; they aren't good all by themselves. An independent
part, let's call it "module", needs to tell other modules how it can
be used, how the other modules can interact with it.

  In C++ this usually happens by class and function declarations: You
tell that a class with a certain name and a certain public interface
exists somewhere, or a function with a certain name and taking
parameters of certain types exists somewhere. Then other code can use
that class or call that function, without having to actually know
where the actual implementation is. (It's the linker which, in the
end, makes the connections in the final binary.)

  The most common way of declaring module interfaces in C++ is by using
so-called header files. There's nothing special about header files per
se, they are just regular C++ code files, but it's just a naming
convention. Usually header files contain public functions and class
declarations only (in rare cases they might contain something else as
well). The advantage of this is that any piece of code wanting to use
that class or call those functions can simply #include that header
file and then do so.


  Nothing. It's just a naming convention. Header files usually contain
only public interface declarations, while cpp files contain actual
code.


  Because you usually want the public declaration of a module to use it.
You don't need (nor want) its implementation (for the reasons stated
earlier). It's extremely rare to have to include actual code (other
than declarations) into other code, and only very special cases are
not a sign of bad design.


  You have to add the library object files into your project. The
library documentation most probably has instructions on how to do that
with Visual Studio (if it doesn't, you'll have to search for some
generic instructions about how to include library objects into the
linking stage in VS).


  Some library include file probably refers to such a name (maybe
through a typedef or preprocessor macro).