Chatper 5 Class 5,6,7
5.5 Summary of Scope and Extent Rules
Functions are extern by default, as are variables defined outside of any function. External functions and variables have external or program scope, which means they are visible across the entire (possible multi-file) program. Functions and external variables that are declared static have file scope, which means their visibility is limited to the source file in which they are defined. Variables defined within a function or block have local scope, and are not visible outside of their enclosing block even if declared static.
There is a fixed limit of functions and external variables, which means that the program has been created prior to execution and exists until the program is finished. Static declaration static also has stable stability, there is a local or freelance extension of non-static local variables, and when they are out-of-scope, they are destroyed. Variables with static borders are initialized to zero, but default default values are not provided with automatic expansions.
In general, a variable can be defined with a storage class extern, static, or auto. The general form of a variable definition is as follows,
<storage class> <type qualifier> <type> <identifier> = <value> ;
where the assignment to an initial value is optional in general, but mandatory for variables qualified by const. For example,
static const double LightSpeed = 2.9979e8; /* m/s */
Additional scope and extent identities. It is possible to define variables with dynamic extent such that their lifetime is managed explicitly by the programmer. Dynamic memory management is performed via the standard library functions malloc() and free(), and is discussed in Chapter 9.
Some other instances of scope are mentioned here for identifiers that are not functions or variables. Preprocessor macros (see Chapter 10) have file scope from the point they are defined to the bottom of the file (unless undefined by #undef). Named labels, such as used by goto (see Section 3.8), have function scope.
5.6 Header Files
Identifiers must the declared in a source file before they can be used. Rather than typing declarations explicitly in each source file that uses them, it is generally convenient to collect common declarations in header files, and include the relevant headers in the source files as required. Inclusion of header files is performed by the C preprocessor as specified by the #include directive.
The #include preprocessor command causes the entire contents of a specified source text file to be processed as if those contents had appeared in place of the #include command [HS95, page 53].
Header files are used to store declarations shared over multiple source files including function prototypes, external variables, constants, macros, and user-defined data types. Collecting these declarations in header files avoids code duplication, and so avoids possible typographical errors and
declaration mismatches. It also makes changes easier to enact as they only need to be made in one place.
Header file names are su xed with .h by convention. The standard library headers are included using angle brackets to enclose the filename as follows.
#include <filename.h>
Angle brackets indicate that the header file is located in some “standard” place according to the compiler-implementation search rules. Usually this means that the header is in the compiler search path. Header files from other libraries may also be included using the angle bracket syntax if they too reside on the compiler search path. A second form of include syntax uses double quotes,
#include "filename.h"
which indicate that the header file is located in some “local” place, usually the current directory. The search for files included using the double-quote syntax begins in the local places and then looks in the standard places. The general intent of the " " form is to denote headers written by the application programmer, while the < > form indicates (usually standard) library headers.
5.7 Modular Programming: Multiple File Programs
Functions creating a C program and external variables should not be compiled at the same time; The source text of the program can be kept in many files, and previously compiled routines may be loaded from libraries [KR88, page 80].
Large-scale C programs are organised so that related functions and variables are grouped into separate source files. Grouping code by source file is central to C’s compilation model, which compiles each file separately to produce individual object modules, and these are later linked to form the complete program. Separate compilation, in conjunction with the C scoping rules, gives rise to the paradigm of modular programming.
This code organisation strategy works as follows. Each source file is a module containing related functions and variables. The declarations of functions and variables (and constants and data-types) to be shared with other modules are stored in an associated header file; this is called the public interface. Access to the module from other modules is restricted to the public interface.
Functions defined in a module that are called only by other functions within that module are declared static. These functions include personal interfaces-functions from within the module, only as part of the internal implementation of the module. Similarly, the external variable used only within the module is declared stable. These private interface declarations are not added to the header file, but are declared at the top of the source file.
The advantages of modular programming are as follows.
• Groups of related functions and variables are collected together. This leads to more intuitive use of a library of code than just a disorganised set of functions. Modules represent a higher level of abstraction than functions.
• Implementation details are hidden behind a public interface. It is useful for preserving users with complex algorithms or non-portable codes. Implementation can be changed later without an active client code (e.g., using a di erent algorithm, or porting platform-specific code to another platform).
• Users of the module can be prevented from accessing only those tasks or variables that are only prepared for private implementation (i.e., for internal use only for modules). It reduces the possibilities by misuse
• Modules are decoupled from the rest of the program, allowing them to be built, tested, and debugged in isolation.
• Modules facilitate team program development where individuals can each work on di erent modules that make up the program.
It is di cult to state definitively the requirements for good modular design, but there are several rules-of-thumb that are generally applicable. First, it is desirable to minimise dependencies between modules. This includes, for example, reducing the use of external variables in public interfaces, which expose the details of the module implementation and disorganize the global namespace. Second, the public interface should be at least; It should only include the functions required to use the module, not just one part of the internal implementation. Similarly, variables, constants, and data types that are not used to share should not be part of the public interface, and should be declared in the source file, not the header file. Finally, it is possible that the area can be as restricted as possible, such local variables are preferred on static variables, which, in turn, are preferred over external variables, and static functions from external functions Is preferred.
