Before playing with ARM Cortex M0, I played with Raspberry Pi and before that Netduino, and before that Arduino. I have been using C# and Python modules and classes, and header files are not needed. But now I guess I need to use header files, which I am not that familiar, and have forgotten the little knowledge I learnt long long time ago.
Header file - Wikipedia
In computer programming, a header file is a file that allows programmers to separate certain elements of a program's source code into reusable files.
Header files commonly contain forward declarations of classes, subroutines, variables, and other identifiers.
Programmers who wish to declare standardized identifiers in more than one source file can place such identifiers in a single header file, which other code can then include whenever the header contents are required. This is to keep the interface in the header separate from the implementation.
The C standard library and C++ standard library traditionally declare their standard functions in header files.
Some recently created compiled languages (such as Java, C#) do not use forward declarations; identifiers are recognized automatically from source files and read directly from dynamic library symbols. This means header files are not needed.
In most modern computer programming languages, programmers can break up programs into smaller components (such as classes and subroutines) and distribute those components among many translation units (typically in the form of source files), which the system can compile separately. Once a subroutine needs to be used somewhere other than in the translation unit where it is defined, a way to refer to it must exist. For example, a function defined in this way in one source file:
int add(int a, int b)
{
return a + b;
}
may be declared (with a function prototype) and then referred to in a second source file as follows:
int add(int, int);
int triple(int x)
{
return add(x, add(x, x));
}
One drawback of this method is that the prototype must be present in all files that use the function.
Another drawback is that if the return type or arguments of the function are changed, these prototypes will have to be updated. This process can be automated with the C preprocessor (i.e., getting any prototype results in getting the latest one).
For example, the following code declares the function in a separate file (the parameter names are not used by the compiler, but they can be useful to programmers):
File "add.h"
#ifndef ADD_H_GUARD
#define ADD_H_GUARD
int add(int a, int b);
#endif
This file uses include guards to avoid multiple definitions of the function. The following code demonstrates how header files are used:
#include "add.h"
int triple(int x)
{
return add(x, add(x,x));
}
Now, every time the code is compiled, the latest function prototypes in add.h will be included in the files using them, avoiding potentially disastrous errors.
Alternatives
Some newer languages (such as Java) dispense with header files and instead use a naming scheme that allows the compiler to locate the source files associated with interfaces and class implementations.
These languages (and perhaps others) preserve type information for functions in the object code, allowing the linker to verify that functions are used correctly.
COBOL and RPG IV have a form of include files called copybooks. Programmers "include" these into the source of the program in a similar way to header files, but they also allow replacing certain text in them with other text. The COBOL keyword for inclusion is COPY, and replacement is done with a REPLACING ... BY ... clause.
Fortran does not require header files per se. However, Fortran 90 and later has two related features: include statements and modules. The former can be used to share a common file containing procedure interfaces, much like a C header, although the specification of an interface is not required for all varieties of Fortran procedures. This approach is not commonly used; instead procedures are generally grouped into modules that can then be referenced with a use statement within other regions of code. For modules, header-type interface information is automatically generated by the compiler, and typically put into separate module (usually *.mod) files in a compiler-dependent format, although some compilers have placed this information directly into object files. Note that the language specification itself does not mandate the creation of any extra files, even though module procedure interfaces are almost universally propagated in this manner.
...
.END
No comments:
Post a Comment