There are two more preprocessor directives available, though they are not very commonly used. They are:
(a) #undef
(b) #pragma
(a) #undef
(b) #pragma
#undef Directive
On some occasions it may be desirable to cause a defined name to become ‘undefined’. This can be accomplished by means of the #undef directive. In order to undefine a macro that has been earlier #defined, the directive,
#undef macro template
can be used. Thus the statement,
#undef PENTIUM
would cause the definition of PENTIUM to be removed from the system. All subsequent #ifdef PENTIUM statements would evaluate to false. In practice seldom are you required to undefine a macro, but for some reason if you are required to, then you know that there is something to fall back upon.
#pragma Directive
This directive is another special-purpose directive that you can use to turn on or off certain features. Pragmas vary from one compiler to another. There are certain pragmas available with Microsoft C compiler that deal with formatting source listings and placing comments in the object file generated by the compiler. Turbo C/C++ compiler has got a pragma that allows you to suppress warnings generated by the compiler. Some of these pragmas are discussed below.
(a) #pragma startup and #pragma exit: These directives allow us to specify functions that are called upon program startup (before main( )) or program exit (just before the program terminates). Their usage is as follows:
void fun1( ) ;
void fun2( ) ;
#pragma startup fun1
#pragma exit fun2
main( )
{
printf ( "\nInside maim" ) ;
}
void fun1( )
{
printf ( "\nInside fun1" ) ;
}
void fun2( )
{
printf ( "\nInside fun2" ) ;
}
And here is the output of the program.
Inside fun1
Inside main
Inside fun2
Note that the functions fun1( ) and fun2( ) should neither receive nor return any value. If we want two functions to get executed at startup then their pragmas should be defined in the reverse order in which you want to get them called.
Inside fun1
Inside main
Inside fun2
Note that the functions fun1( ) and fun2( ) should neither receive nor return any value. If we want two functions to get executed at startup then their pragmas should be defined in the reverse order in which you want to get them called.
(b) #pragma warn: This directive tells the compiler whether or not we want to suppress a specific warning. Usage of this pragma is shown below.
#pragma warn –rvl /* return value */
#pragma warn –par /* parameter not used */
#pragma warn –rch /* unreachable code */
int f1( )
{
int a = 5 ;
}
void f2 ( int x )
{
printf ( "\nInside f2" ) ;
}
int f3( )
{
int x = 6 ;
return x ;
x++ ;
}
void main( )
{
f1( ) ;
f2 ( 7 ) ;
f3( ) ;
}
If you go through the program you can notice three problems immediately. These are:
(a) Though promised, f1( ) doesn’t return a value.
(b) The parameter x that is passed to f2( ) is not being used anywhere in f2( ).
(c) The control can never reach x++ in f3( ).
If we compile the program we should expect warnings indicating the above problems. However, this does not happen since we have suppressed the warnings using the #pragma directives. If we replace the ‘–’ sign with a ‘+’ then these warnings would be flashed on compilation. Though it is a bad practice to suppress warnings, at times it becomes useful to suppress them. For example, if you have written a huge program and are trying to compile it, then to begin with you are more interested in locating the errors, rather than the warnings. At such times you may suppress the warnings. Once you have located all errors, then you may turn on the warnings and sort them out.
f1( ) ;
f2 ( 7 ) ;
f3( ) ;
}
If you go through the program you can notice three problems immediately. These are:
(a) Though promised, f1( ) doesn’t return a value.
(b) The parameter x that is passed to f2( ) is not being used anywhere in f2( ).
(c) The control can never reach x++ in f3( ).
If we compile the program we should expect warnings indicating the above problems. However, this does not happen since we have suppressed the warnings using the #pragma directives. If we replace the ‘–’ sign with a ‘+’ then these warnings would be flashed on compilation. Though it is a bad practice to suppress warnings, at times it becomes useful to suppress them. For example, if you have written a huge program and are trying to compile it, then to begin with you are more interested in locating the errors, rather than the warnings. At such times you may suppress the warnings. Once you have located all errors, then you may turn on the warnings and sort them out.
No comments:
Post a Comment