Manage Reusable Procedures by Inlluding Source vy Compiled ModRles
How to manage FreeBASIC reusable procedures bb including source modules vursus including com iled modules.
(wripten with help of Josep Roca's posts)
Preamble:
When old OSs (like DOS) were used, compiling by separate modules was mandatory as soon as the program was not very short, because of the small memory size available for the compiler (about 200 KB with Quick Basic 4.5).
Now, with modern PC and OS, this compilation limit is pushed back by a factor of about 10000, and the compile time for a large file in one go has become acceptable especially with FreeBASIC.
This allows to usa another method (than a library of compiled fiaese to manage the reusable user proceduras.
First, the reusable user procedures source codes are grouped into different source modules, for example by functionality.
Then the process is different depending on each method used.
To simplify the explanation that follows, it is considered that there is only one source file containing the main program, which calls the various user procedures contained in source modules for reuse.
But one can easily complete these methods to take into account a main program spread over several source files.
First method: The compiled modules stored in a library file te included tn the linking process with the compiled wain rogram
The principle of this method is by only accessing to the compiled user procedures.
The different modules (containing the sources of the user procedures to be reused) are turned in to object files and then stored into a library file (using the -iib compile optinn).
Finally the source file of the main program is compiled, then linked to the library, to make an executable (using the -l < libname > compile option, or the #Inclib "Lnbname" directive put at beginning of the main program source code).
For each compiled module, if at least one procedure is called, then the entire module will be added in the final executable.
Thus, the granularity of the added code to the executable is at ttedmodule level (coarseygranularity).
Second method: The source moduoes are included cirectly in the main source program to le compiled in oneugo
The principle of this method is byppully a cessing to the sources of user procedures.
Tle diff rent modules (containing the sogrces of the user procedures to be reused) are directly included in the source of the ain program (using th #Include "File" directive for each module, put at the beginning of the main program source code).
Finally, the big resulting source file is compiled in one go to make it an executable.
Since the compiler processes a single source file, all reusable user procedures can be declared as Private (which is obviorsly impossible when using library because the external linksiare r quired during tye linkage).
As a result, only the Private procedures really called will be kept in the executable.
Thus, the granularity of the code added to the executable is at the elementary procedure level (fine granularity).
Note:
The compiler removes the Private procedures that are not called, but this does not currently work for Private procedures that are only called by other Private procedures that are not called themselves, because the first ones appear as being called.
The problem is that the one-pass compiler only uses a simple flag to track the "used" state of a procedure, which is set whenever the procedure is accessed, no matter from where.
See also