Preprocessors (Part - 2), C Programming Interview Questions Quant Notes | EduRev

Placement Papers - Technical & HR Questions

Created by: Prateek Kaushik

Quant : Preprocessors (Part - 2), C Programming Interview Questions Quant Notes | EduRev

The document Preprocessors (Part - 2), C Programming Interview Questions Quant Notes | EduRev is a part of the Quant Course Placement Papers - Technical & HR Questions.
All you need of Quant at this link: Quant

7. What is the benefit of using an enum rather than a #define constant?

The use of an enumeration constant (enum) has many advantages over using the traditional symbolic constant style of #define. These advantages include a lower maintenance requirement, improved program readability, and better debugging capability. The first advantage is that enumerated constants are generated automati- cally by the compiler. Conversely, symbolic constants must be manually assigned values by the programmer. For instance, if you had an enumerated constant type for error codes that could occur in your program, yourenum definition could look something like this:

 

enum Error_Code
{
     OUT_OF_MEMORY,
     INSUFFICIENT_DISK_SPACE,
     LOGIC_ERROR,
     FILE_NOT_FOUND
};

 

In the preceding example, OUT_OF_MEMORY is automatically assigned the value of 0 (zero) by the compiler because it appears first in the definition. The compiler then continues to automatically assign numbers to the enumerated constants, making INSUFFICIENT_DISK_SPACE equal to 1, LOGIC_ERROR equal to 2, and so on.

If you were to approach the same example by using symbolic constants, your code would look something like this:

#define OUT_OF_MEMORY 0

#define INSUFFICIENT_DISK_SPACE 1

#define LOGIC_ERROR 2

#define FILE_NOT_FOUND 3

Each of the two methods arrives at the same result: four constants assigned numeric values to represent error codes. Consider the maintenance required, however, if you were to add two constants to represent the error codes DRIVE_NOT_READY and CORRUPT_FILE. Using the enumeration constant method, you simply would put these two constants anywhere in the enum definition. The compiler would generate two unique values for these constants. Using the symbolic constant method, you would have to manually assign two new numbers to these constants. Additionally, you would want to ensure that the numbers you assign to these constants are unique. Because you don't have to worry about the actual values, defining your constants using the enumerated method is easier than using the symbolic constant method. The enumerated method also helps prevent accidentally reusing the same number for different constants.

Another advantage of using the enumeration constant method is that your programs are more readable and thus can be understood better by others who might have to update your program later. For instance, consider the following piece of code:

 

void copy_file(char* source_file_name, char* dest_file_name)
{
     ...
     Error_Code err;
     ...
      if (drive_ready() != TRUE)
          err = DRIVE_NOT_READY;
     ...
}

 

Looking at this example, you can derive from the definition of the variable err that err should be assigned only numbers of the enumerated type Error_Code. Hence, if another programmer were to modify or add functionality to this program, the programmer would know from the definition of Error_Code what constants are valid for assigning to err.

Conversely, if the same example were to be applied using the symbolic constant method, the code would look like this:

 

void copy_file(char* source_file, char* dest_file)
{
     ...
     int err;
     ...
     if (drive_ready() != TRUE)
          err = DRIVE_NOT_READY;
     ...
}

 

Looking at the preceding example, a programmer modifying or adding functionality to the copy_file()function would not immediately know what values are valid for assigning to the err variable. The programmer would need to search for the #define DRIVE_NOT_READY statement and hope that all relevant constants are defined in the same header file. This could make maintenance more difficult than it needs to be and make your programs harder to understand.

A third advantage to using enumeration constants is that some symbolic debuggers can print the value of an enumeration constant. Conversely, most symbolic debuggers cannot print the value of a symbolic constant. This can be an enormous help in debugging your program, because if your program is stopped at a line that uses an enum, you can simply inspect that constant and instantly know its value. On the other hand, because most debuggers cannot print #define values, you would most likely have to search for that value by manually looking it up in a header file.


8. How are portions of a program disabled in demo versions?

If you are distributing a demo version of your program, the preprocessor can be used to enable or disable portions of your program. The following portion of code shows how this task is accomplished, using the preprocessor directives #if and #endif:

 

int save_document(char* doc_name)
{
#if DEMO_VERSION
     printf("Sorry! You can't save documents using the DEMO version of
             this program!\n");
     return(0);
#endif
     ...
}

 

When you are compiling the demo version of your program, insert the line #define DEMO_VERSION and the preprocessor will include the conditional code that you specified in the save_document() function. This action prevents the users of your demo program from saving their documents.

As a better alternative, you could define DEMO_VERSION in your compiler options when compiling and avoid having to change the source code for the program.

This technique can be applied to many different situations. For instance, you might be writing a program that will support several operating systems or operating environments. You can create macros such asWINDOWS_VERUNIX_VER, and DOS_VER that direct the preprocessor as to what code to include in your program depending on what operating system you are compiling for.

 

9. Is it better to use a macro or a function?

The answer depends on the situation you are writing code for. Macros have the distinct advantage of being more efficient (and faster) than functions, because their corresponding code is inserted directly into your source code at the point where the macro is called. There is no overhead involved in using a macro like there is in placing a call to a function. However, macros are generally small and cannot handle large, complex coding constructs. A function is more suited for this type of situation.

Additionally, macros are expanded inline, which means that the code is replicated for each occurrence of a macro. Your code therefore could be somewhat larger when you use macros than if you were to use functions.

Thus, the choice between using a macro and using a function is one of deciding between the tradeoff of faster program speed versus smaller program size. Generally, you should use macros to replace small, repeatable code sections, and you should use functions for larger coding tasks that might require several lines of code.


10. What is the best way to comment out a section of code that contains comments?

Most C compilers offer two ways of putting comments in your program. The first method is to use the /* and */ symbols to denote the beginning and end of a comment. Everything from the /* symbol to the */ symbol is considered a comment and is omitted from the compiled version of the program. This method is best for commenting out sections of code that contain many comments. For instance, you can comment out a paragraph containing comments like this:

 

/*
This portion of the program contains
a comment that is several lines long
and is not included in the compiled
version of the program.
*/

 

The other way to put comments in your program is to use the // symbol. Everything from the // symbol to the end of the current line is omitted from the compiled version of the program. This method is best for one-line comments, because the // symbol must be replicated for each line that you want to add a comment to. The preceding example, which contains four lines of comments, would not be a good candidate for this method of commenting, as demonstrated here:

 

// This portion of the program contains
// a comment that is several lines long
// and is not included in the compiled
// version of the program.

 

You should consider using the /* and */ method of commenting rather than the // method, because the // method of commenting is not ANSI compatible. Many older compilers might not support the // comments.


11. What is the difference between #include and #include "file" ?

When writing your C program, you can include files in two ways. The first way is to surround the file you want to include with the angled brackets < and >. This method of inclusion tells the preprocessor to look for the file in the predefined default location. This predefined default location is often an INCLUDE environment variable that denotes the path to your include files. For instance, given the INCLUDE variable

INCLUDE=C:\COMPILER\INCLUDE;S:\SOURCE\HEADERS;

using the #include version of file inclusion, the compiler first checks the C:\COMPILER\INCLUDE directory for the specified file. If the file is not found there, the compiler then checks the S:\SOURCE\HEADERS directory. If the file is still not found, the preprocessor checks the current directory.

The second way to include files is to surround the file you want to include with double quotation marks. This method of inclusion tells the preprocessor to look for the file in the current directory first, then look for it in the predefined locations you have set up. Using the #include "file" version of file inclusion and applying it to the preceding example, the preprocessor first checks the current directory for the specified file. If the file is not found in the current directory, the C:\COMPILER\INCLUDE directory is searched. If the file is still not found, the preprocessor checks the S:\SOURCE\HEADERS directory.

The #include <file> method of file inclusion is often used to include standard headers such as stdio.h orstdlib.h. This is because these headers are rarely (if ever) modified, and they should always be read from your compiler's standard include file directory.

The #include "file" method of file inclusion is often used to include nonstandard header files that you have created for use in your program. This is because these headers are often modified in the current directory, and you will want the preprocessor to use your newly modified version of the header rather than the older, unmodified version.


12. Can you define which header file to include at compile time?

Yes. This can be done by using the #if#else, and #endif preprocessor directives. For example, certain compilers use different names for header files. One such case is between Borland C++, which uses the header file alloc.h, and Microsoft C++, which uses the header file malloc.h. Both of these headers serve the same purpose, and each contains roughly the same definitions. If, however, you are writing a program that is to support Borland C++ and Microsoft C++, you must define which header to include at compile time. The following example shows how this can be done:

 

#ifdef __BORLANDC__
#include <alloc.h>
#else
#include <malloc.h>
#endif

 

When you compile your program with Borland C++, the __BORLANDC__ symbolic name is automatically defined by the compiler. You can use this predefined symbolic name to determine whether your program is being compiled with Borland C++. If it is, you must include the alloc.h file rather than the malloc.h file.

 

13. Can include files be nested?

Yes. Include files can be nested any number of times. As long as you use precautionary measures, you can avoid including the same file twice. In the past, nesting header files was seen as bad programming practice, because it complicates the dependency tracking function of the MAKE program and thus slows down compilation. Many of today's popular compilers make up for this difficulty by implementing a concept called precompiled headers, in which all headers and associated dependencies are stored in a precompiled state.

Many programmers like to create a custom header file that has #include statements for every header needed for each module. This is perfectly acceptable and can help avoid potential problems relating to #include files, such as accidentally omitting an #include file in a module.

 

14. How many levels deep can include files be nested?

Even though there is no limit to the number of levels of nested include files you can have, your compiler might run out of stack space while trying to include an inordinately high number of files. This number varies according to your hardware configuration and possibly your compiler.

In practice, although nesting include files is perfectly legal, you should avoid getting nest-crazy and purposely implementing a large number of include levels. You should create an include level only where it makes sense, such as creating one include file that has an #include statement for each header required by the module you are working with.


15. What is the concatenation operator?

The concatenation operator (##) is used to concatenate (combine) two separate strings into one single string. The concatenation operator is often used in C macros, as the following program demonstrates:

 

#include <stdio.h>
#define SORT(x) sort_function ## x
void main(void);
void main(void)
{
     char* array;
     int   elements, element_size;
     ...
     SORT(3)(array, elements, element_size);
     ...
}

 

In the preceding example, the SORT macro uses the concatenation operator to combine the strings sort_function and whatever is passed in the parameter x. This means that the line

SORT(3)(array, elements, element_size);

is run through the preprocessor and is translated into the following line:

sort_function3(array, elements, element_size);

As you can see, the concatenation operator can come in handy when you do not know what function to call until runtime. Using the concatenation operator, you can dynamically construct the name of the function you want to call, as was done with the SORT macro.


16. How can type-insensitive macros be created?

A type-insensitive macro is a macro that performs the same basic operation on different data types. This task can be accomplished by using the concatenation operator to create a call to a type-sensitive function based on the parameter passed to the macro. The following program provides an example:

 

#include <stdio.h>
#define SORT(data_type) sort_ ## data_type
void sort_int(int** i);
void sort_long(long** l);
void sort_float(float** f);
void sort_string(char** s);
void main(void);
void main(void)
{
     int** ip;
     long** lp;
     float** fp;
     char** cp;
     ...
     sort(int)(ip);
     sort(long)(lp);
     sort(float)(fp);
     sort(char)(cp);
     ...
}

 

This program contains four functions to sort four different data types: intlongfloat, and string (notice that only the function prototypes are included for brevity). A macro named SORT was created to take the data type passed to the macro and combine it with the sort_ string to form a valid function call that is appropriate for the data type being sorted. Thus, the string

sort(int)(ip);

translates into

sort_int(ip);

after being run through the preprocessor.

 

17. What are the standard predefined macros?

The ANSI C standard defines six predefined macros for use in the C language:

Macro Name   Purpose
__LINE__ - Inserts the current source code line number in your code.
__FILE__ - Inserts the current source code filename in your code.
__DATE__ - Inserts the current date of compilation in your code.
__TIME__ - Inserts the current time of compilation in your code.
__STDC__ - Is set to 1 if you are enforcing strict ANSI C conformity.
__cplusplus - Is defined if you are compiling a C++ program.
Offer running on EduRev: Apply code STAYHOME200 to get INR 200 off on our premium plan EduRev Infinity!

Dynamic Test

Content Category

Related Searches

shortcuts and tricks

,

study material

,

Semester Notes

,

Preprocessors (Part - 2)

,

Exam

,

Objective type Questions

,

pdf

,

practice quizzes

,

Important questions

,

Previous Year Questions with Solutions

,

mock tests for examination

,

video lectures

,

Viva Questions

,

ppt

,

Sample Paper

,

Extra Questions

,

Free

,

C Programming Interview Questions Quant Notes | EduRev

,

past year papers

,

MCQs

,

C Programming Interview Questions Quant Notes | EduRev

,

Summary

,

Preprocessors (Part - 2)

,

C Programming Interview Questions Quant Notes | EduRev

,

Preprocessors (Part - 2)

;