Assembling C++ files to Form an Application
Writing a C++ Application – Part 3
Forward: In this part of the series, I talk about assembling or joining C++ files to form an application during compilation.
By: Chrysanthus Date Published: 7 Feb 2013
Introduction
A Long Application
Imagine that you have one file that is very long and is operating well (after compilation). This file has the C++ main function. Also assume that different portions of the file are interdependent. This file can be broken down into shorter files. If you do that, you would have to join the files with the #include preprocessing directives. With each included file having its own #include directive. The included files are included to the file that has the C++ main function. After the inclusions, the resulting file will still operate well (after compilation).
I call such a file a long file or long application. The phrase “long application” here is my vocabulary. It is contrasted to a large file as explained below. A very long file in this light, is an application.
A Large Application
You can write a C++ application consisting of a number of files that are almost independent from one another, similar to the two files (sampleEntities.cpp and mainFile.cpp), we had in the previous part of the series. There is also a third file, the header file. This header file was included in the two files. Our focus here is the two files. An application compiled with almost independent files like these forms a large application.
With this arrangement, you end up with an effective large file or large application. The phrase, “large application” here, is my vocabulary.
Note, long or large application here, refers to C++ programming. Maybe the same vocabulary can be applied to other languages.
Disadvantage of Long Application
The disadvantage with long applications is that, the amount of code is limited and small. I am still to come across the limit of the amount of code for large applications. A large application takes far more code than a long application. If you are writing a long application, as you continue to increase the code, at a certain point, the compiler will complain (issue an error message) and stop compilation, unless you reduce the code to its limit or below. I have never witness a similar complaint with a large application. I have always been adding files upon files in parallel (see below) to a large application.
To write a large application, you need to know how to prepare and use header files. I explained the preparation and use of headers and header files in the previous two parts of this series. I will talk about header file and namespace in one of the following parts of this series. To prepare a long application, you do not need to understand much about header files.
To compile a long application in my MinGW compile, a command line like,
g++ aMainFile.cpp -o aMainFile.exe
will do. Here, there is only one .cpp file and one resulting executable file. The one .cpp file has the main function. To compile a large application, you need to type the names of the parallel (see below) files on the left of the switch, -o; something like,
g++ fileA.cpp fileB.cpp fileC.cpp -o appFile.exe
where fileA.cpp, fileB.cpp and fileC.cpp are the parallel files and appFile.exe is the resulting executable file. fileC.cpp has the C++ main function. The header file (or header files) is (are) not in the compiler command line. A header file, is included in one or more of the parallel files.
Vertical and Parallel Files
A long application consists of vertical files. Such vertical files are very dependent on one another. A large application consists of parallel files. Such parallel files are almost independent on one another. Vertical files are join or assembled using the #include directive for each file. Parallel files are joined or assembled at the compiler command line. Also, to join or assemble parallel files, you would need at least one header file of your own (writing). This header file is included at the top of the parallel files. Nothing stops you from having more than one header file of your own, for your application. The header files will have to be included at the top of the parallel files.
The phrase, “vertical files” and “parallel files” are my vocabulary.
The files of a long application can still be written by different people. The long application is a very long file. Imagine that a long application consists of 10 files. The bottommost file has the main function. Assume that an entity has been defined in the topmost file, by someone else. Assume that you are the one writing the fifth file, from bottom. If you want to define an entity and for some reason you think that it might already have been defined in the top file, then you would code something like this in the fifth file:
#ifndef entityname
#define entityName
#endif
#ifndef means “if not defined”
The #ifndef preprocessing directive is applicable to long applications. It is not really applicable to large applications.
Combined Long and Large Application
Nothing stops you from preparing an application, which is a combination of long and large applications. However, I always avoid having long features in my application. Also, there is no big application that is large consisting ideally of only parallel files. The vertical nature is usually from the header files.
That is it for this part of the series. We stop here and continue in the next part.
Chrys
Related Courses
C++ CourseRelational Database and Sybase
Windows User Interface
Computer Programmer – A Jack of all Trade – Poem
NEXT