Preprocessor: All the preprocessor commands written in a high level language are processed by the preprocessor before compiler takes over.
Example: "#define MAX_ROWS 10"
Preprocessor finds all the places and replaces MAX_ROWS with 10 in the files of the project.
Compiler: This software, converts the code written in high-level language into object file. Compiler converts all the files of a given project at once.
A preprocessor directive is an instruction that the preprocessor should perform in order to create a valid translation unit suitable for compilation by the compiler. A header file is simply a file containing source code (and possibly containing more preprocessor directives). A preprocessor directive is used to import the content of a header file into another file.
Conditional compilation is achieve through preprocessor directives. First, define the preprocessor symbols upon which conditional compilation depends, then test them using #if and #else preprocessor directives. A #endif directive indicates the end of the nearest enclosing conditional block, thus conditional blocks may be nested. The following example demonstrates how we can conditionally define debug or production code based upon the absence or existence of the NDEBUG symbol: #ifdef NDEBUG /* all C code within this block is compiled when NDEBUG is defined (production code) */ #else /* all C code within this block is compiled when NDEBUG is not defined (debug code) */ #endif Note that the NDEBUG symbol is typically defined via the command line, however symbols can also be defined or undefined via the source using the #define and #undefine directives. For instance, header files typically require guards to protect against being included more than once in a compilation and preprocessor directives provide the conventional means of ensuring that is the case: // myheader.h #ifndef _MYHEADER_H_ #define _MYHEADER_H_ // all header code goes here... #endif By convention, preprocessing symbols (macros) are defined with all uppercase and are intentionally ugly to avoid any confusion with C identifiers. Header guards must be unique to each header thus they are typically based upon the header file name itself.
Source code written in Java is simple. There is no preprocessor, no #define and related capabilities, no typedef, and absent those features, no longer any need for header files. Instead of header files, Java language source files provide the declarations of other classes and their methods.
Preprocessor directives are used to mark code that is specific to a particular compiler and thus to a specific machine architecture. In this way, programmers can write cross-platform code in the same source and let the compiler decide which parts of the source to compile and which to ignore. In reality, the compiler never actually sees the preprocessor directives since the preprocessor creates new files containing only the code that is to be compiled. Hence the preprocessor is often called the precompiler. Normally, the intermediate source files are deleted as they are compiled, however your development environment should contain an option that allows you to view these files so you can see what the compiler actually works with. In C and C++, all preprocessor directives have a leading # symbol, such as #include and #define. #include is by far the most common preprocessor directive. When the precompiler encounters a #include statement, the named header file is essentially copy/pasted in place of the directive. However, all header files should also contain #ifndef header guards to ensure headers are only included once per compilation and these have to be preprocessed as well. Macro definitions are also preprocessed, replacing all instances of the macro symbol with the definition. Macro functions are also inline expanded but since the compiler only sees the expanded code, never the macro itself, the compiler cannot help you debug errant macros. This is why non-trivial macro functions are best avoided.
The preprocessor is the program that prepares your source files for compilation. In some implementations the preprocessor is a separate program from the compiler but in others it is part of the compiler program itself. Regardless, preprocessing occurs before compilation, hence the preprocessor is often commonly referred to as the precompiler. The preprocessor parses each of your source files (*.c files) and generates intermediate files that contain nothing but pure C code. Note that the compiler never sees your source code, it only sees the code output by the preprocessor. Each intermediate file output by the preprocessor is known as a translation unit. The compiler converts each translation unit into an object file, which is part machine code, part symbol table. Once all translation units have been compiled, the linker can examine the symbol tables within the object files and thus link the machine code together to produce the final executable. You might think that your source files are already pure C code but they are not. For instance, source files usually contain user-comments but a user-comment is not C code; it is human-readable code. So part of the preprocessor's job is to strip out all user-comments. This is why compiler's ignore user-comments; they never see them! Aside from stripping out comments, the primary role of the preprocessor is to act upon the preprocessor directives within your source files. That is, header files are imported into your source code, conditional compilation is applied and macros are expanded. Importing headers is relatively straightforward. The #include directive is simply replaced with the contents of the specified header file in the intermediate file. However, the imported file must be preprocessed as it is imported because header files often include directives of their own, which may including importing other header files. In some cases, a header file might end up being included two or more times in a single translation unit which is why we use conditionally compiled header guards to ensure each header is included only once. Conditional compilation relies upon symbols that are either defined or not defined. We can use directives to define or undefine symbols as appropriate, although its best to supply conditional compilation symbols via the command line. We can test if a symbol is defined or not by using the #ifdef and #ifndef directives as appropriate. Depending on the evaluation of the test, the code that follows is either included or excluded from the intermediate file, up to the corresponding #endif directive. Header guards make use of this to define a new symbol if the header hasn't already been included. If the symbol already exists, then we can ignore the content because it has already been included. In addition, the #else directive allows the programmer to provide alternate versions of code, only one of which will be included in the intermediate file. This is useful when writing cross-platform code by providing code specific to each platform. Macros are the most complex part of preprocessing. Consider the following macro definitions: #define WHEREARG __FILE__, __LINE__ #define WHERESTR "[file %s, line %d]: " #define DEBUGPRINT2(...) fprintf(stderr, __VA_ARGS__) #define DEBUGPRINT(_fmt, ...) DEBUGPRINT2(WHERESTR _fmt, WHEREARG, __VA_ARGS__) The first two macros are simple text replacements while the second two are macro functions. All four work together. The DEBUGPRINT macro function is the macro we will actually use in our code. For instance: DEBUGPRINT("x=%d\n", x); If we suppose this line of code appears on line 42 of the source file "foo.c", this macro would expand to: fprintf(stderr, "[file %s, line %d]: x=%d\n", "foo.c", 42, x); To understand how it works, we need to look at the individual macro substitutions performed by the preprocessor. First we substitute the original DEBUGPRINT macro function with its definition: DEBUGPRINT2(WHERESTR "x=%d\n", WHEREARG, x); Note that arguments we supplied are substituted into the arguments of the macro function. This substituted code is another macro function. After simple text substitution of WHERESTR and WHEREARG we get: DEBUGPRINT2("[file %s, line %d]: x=%d\n", __FILE__, __LINE__, x); Note that when two strings are adjacent in a macro, the preprocessor automatically appends one to the other. Again, we have two simple text substitution macros. The __FILE__ and __LINE__ macros are actually defined by the preprocessor. Given that the original function was called from line 42 of the "foo.c" file, the macro will now expand to: DEBUGPRINT2("[file %s, line %d]: x=%d\n", "foo.c", 42, x); Finally, we substitute the DEBUGPRINT2 macro with its definition, substituting the supplied arguments accordingly: fprintf(stderr, "[file %s, line %d]: x=%d\n", "foo.c", 42, x); Note that the compiler never sees the macros, it only sees the code generated by the preprocessor. If the expanded code contains any compiler errors, the compiler cannot identify the source of the error. In addition, macros are not type safe and may introduce subtle bugs that are extremely difficult to track down. When used appropriately, they can greatly simplify your coding however the general rule is don't use them unless you have to. If you find yourself using a lot of macros to overcome a language limitation, then you're probably using the wrong programming language for the task at hand.
the program contains the which are coding like as our header file ,void main,library function etc.
pata nhn
Yes, it often does.
Conditional compilation is achieve through preprocessor directives. First, define the preprocessor symbols upon which conditional compilation depends, then test them using #if and #else preprocessor directives. A #endif directive indicates the end of the nearest enclosing conditional block, thus conditional blocks may be nested. The following example demonstrates how we can conditionally define debug or production code based upon the absence or existence of the NDEBUG symbol: #ifdef NDEBUG /* all C code within this block is compiled when NDEBUG is defined (production code) */ #else /* all C code within this block is compiled when NDEBUG is not defined (debug code) */ #endif Note that the NDEBUG symbol is typically defined via the command line, however symbols can also be defined or undefined via the source using the #define and #undefine directives. For instance, header files typically require guards to protect against being included more than once in a compilation and preprocessor directives provide the conventional means of ensuring that is the case: // myheader.h #ifndef _MYHEADER_H_ #define _MYHEADER_H_ // all header code goes here... #endif By convention, preprocessing symbols (macros) are defined with all uppercase and are intentionally ugly to avoid any confusion with C identifiers. Header guards must be unique to each header thus they are typically based upon the header file name itself.
what is the difference between titles and headings in general.
Classes and structures can be put in a header file the same way you would use them in a main program; the only difference is that they are placed in a separate file, called a header file. Then, after creating a new file, include that new file with the definition by the use of the preprocessor #include statement.
The page header repeats on every page. The report header is just on the first page.
The preprocessor (or precompiler) processes all the preprocessor directives and macro definitions within your source files. In other words it creates modified source files where all directives and macros are completely stripped out and replaced by their respective definitions. For instance, each #include statement in your source inserts the named header just as if you'd copy/pasted that entire header into your source. However, prior to insertion, the header itself must be preprocessed, thus it is the modified code that is physically inserted. Once inserted, the #include directive is removed from the modified source. Since the compiler works with modified source files (intermediate sources), the compiler never sees your macro definitions and therefore cannot help you debug them. A macro is a primitive text replacement system so if this creates invalid code, a compiler error occurs but the compiler cannot tell you where that error originated because it is processing code that does not exist in your source.
Header files are not much different from usual cpp files. There are basically two different things. It's file extension: you need to choose "header file" when you create it or save as .h file. Second is header files do not have main() function. When you are done with you header file do not forger to include it in your project by writing preprocessor directive:#include "your_header_file.h"
Source code written in Java is simple. There is no preprocessor, no #define and related capabilities, no typedef, and absent those features, no longer any need for header files. Instead of header files, Java language source files provide the declarations of other classes and their methods.
osi add header at each layer but SNA add header at bottom layers
Preprocessor directives are used to mark code that is specific to a particular compiler and thus to a specific machine architecture. In this way, programmers can write cross-platform code in the same source and let the compiler decide which parts of the source to compile and which to ignore. In reality, the compiler never actually sees the preprocessor directives since the preprocessor creates new files containing only the code that is to be compiled. Hence the preprocessor is often called the precompiler. Normally, the intermediate source files are deleted as they are compiled, however your development environment should contain an option that allows you to view these files so you can see what the compiler actually works with. In C and C++, all preprocessor directives have a leading # symbol, such as #include and #define. #include is by far the most common preprocessor directive. When the precompiler encounters a #include statement, the named header file is essentially copy/pasted in place of the directive. However, all header files should also contain #ifndef header guards to ensure headers are only included once per compilation and these have to be preprocessed as well. Macro definitions are also preprocessed, replacing all instances of the macro symbol with the definition. Macro functions are also inline expanded but since the compiler only sees the expanded code, never the macro itself, the compiler cannot help you debug errant macros. This is why non-trivial macro functions are best avoided.
A header is at the top of the page, while a footer is at the bottom. Titles, dates, etc, can be put into the header and printed on every page. While the footer may have page numbers (1) or (1 of 6) and so on, and printed at the bottom of the page.