Syntax:
==========================================
==========================================
Suppose you want to print a Character for 50 (or so) Times before entering Main ().
Here the code goes:
#include "stdio.h"
#include "conio.h"
void PrintChars ()
{
char cChar;
int iTimes, iLoop;
printf ("\n Enter a Character to print: ");
scanf ("%c", &cChar);
printf ("\n How many times you want \'%c\' to print", cChar);
scanf ("%d", iTimes);
for ( iLoop=1; iLoop <= iTimes; iLoop++)
printf ("%c", cChar);
}
#pragma startup PrintChars
void main ()
{
printf ("Entering Main()...\n");
getch();
printf ("Exit from Main()...\n");
getch();
}
The #pragma directive is a compiler specific instruction. There are many things you can tell the compiler. For instance, the #pragma pack n directive tells the compiler to override the /Zpn command line argument and to use a new default structure packing value. To see all of the possible #pragma directives, go to online help, and index by #pragma directives, C/C++. You probably only need to type in #pra and then click on C/C++ to get this far.
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 #define preprocessor directive is severely overused in my opinion. Often, you will see programmers write something like this: # define MAX(a, b) (((a) > (b))? (a) : (b)) However doing so is rather dangerous, because the preprocessor replaces things textually. This means that if you pass in a call to a function, it may happen twice, for example: MAX(++i, j) will be expanded to (((++i) > (j))? (++i) : (j)) which is bad. A much safer (and more common) example is that people will use #define to create a constant variable: #define MYCONST 10 This too can cause problems if another file depends on the constant and certain other conditions are met. A safer alternative is to declare a const variable. The one advantage of using #define for literal constants is that the number will not be stored in memory attached to an object like a const variable will.
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.
Conditional inclusion is a trick that some languages must use to prevent multiple declarations of the same symbols. A prime example would be "C++", that typically breaks the interface and implementation definitions into .h and .cpp files, respectively. Since it is common that the .h file will be included in numerous .cpp files that define symbols needed by the implementation, a common method is to use the #define preprocessor directive. For your file "MyClass.h":#ifndef __MyClass_H__#define __MyClass_H__... class definition goes here ...#endif
a preprocessor directive that is not an specified ISO standard that controls actions of complier and linker
The #pragma directive is a compiler specific instruction. There are many things you can tell the compiler. For instance, the #pragma pack n directive tells the compiler to override the /Zpn command line argument and to use a new default structure packing value. To see all of the possible #pragma directives, go to online help, and index by #pragma directives, C/C++. You probably only need to type in #pra and then click on C/C++ to get this far.
You can use the preprocessor directive #define, or you can describe a variable in the body of main(). With the preprocessor directive you can make the variable accessible even out of your current project.
Pragma directive forces processor to use specific advantages for particular processors such as Hyper Threading, multi cores and so on.
The Prime Directive is a basic rule in Star Trek.His directive is that we seek an amiable solution. What is your directive, boss?
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.
DOD 8100.2
Manual Startup. Use services.msc in command prompt to set the startup.
Msconfig Use Software Explorer to view and stop startup programs in Vista.
PHP is "Hypertext Preprocessor", use google translator to make it Chinese :D
The simple answer is that directives are symbols that instruct or direct the preprocessor, while declarations are C++ symbols that are processed by the C++ compiler. The preprocessor and the compiler are essentially two completely separate operations. The preprocessor is tasked with modifying your source files in order to produce temporary intermediate source files which the compiler can process more efficiently. These intermediate files contain nothing but C++ code, thus the preprocessor's primary job is to strip out all the comments from your source files. Preprocessor directives are used to instruct the preprocessor in all other modifications, such as where and when to include one file within another and which sections of code are valid for a particular build. This is achieved by #define directives, in conjunction with #ifdef, #else and #endif directives. The #define directive defines a symbol. As the preprocessor encounters these directives, the symbols are placed in a definition table, which includes all the symbols that were initially passed via the command line. Some symbols have no value assigned to them; their presence in the table is sufficient to know they are defined, and the preprocessor can simply act according to whether a symbol is currently defined or not. The #undef directive is the antidote to #define, allowing symbols to be undefined (removed from the table) by the preprocessor. However, #define can also be used to assign a value to a symbol. This value acts a text replacement for the symbol, thus wherever the symbol is encountered within your code (outwith any other directives), the symbol is replaced with the text value associated with that symbol. These are known as macros. #define can also be used to declare macro functions, where the text replacement includes one or more arguments within parenthesis, followed by C++ code that processes those arguments. Thus all occurrences of the symbol in your code must include an argument list with the same number of arguments as the macro directive. The preprocessor then inline expands the macro function, replacing its arguments with the formal arguments provided by your code. The problem with #define in general is that it is not a C++ statement, it is a macro, and macros are not subject to the strong-typing that is fundamental to C++. So while you can use #define to declare literal constants, those constants are untyped. Moreover, since the compiler never sees the macro definition (it is stripped from the intermediate file), any errors that occur as a result of a macro expansion cannot be sourced back to the macro, which makes debugging difficult at best. In the case of macro functions, the debugger cannot help you at all, you're completely on your own. Thus when you have the option to use directives or declarations, always go with a declaration. C++ code is type safe, can be easily debugged, is easier to maintain, and usually results in much smaller compiled code. Only use the preprocessor to generate code that would be difficult or impossible to generate with the compiler alone. In other words, use directives specifically to direct the preprocessor. Never rely on them to generate C++ code unless you have no other option, or it would greatly simplify a far more complex C++ implementation.
I think we can use #pragma pack(1) By this the structure will he paked in 1 byte order so there will be no waste of memory .