In the following example, the compiler will concatenate the two strings into a single string:

printf("This is a string " "and this is another string.");

Which is probably what you intended anyway.

Because C and C++ are free form languages, adjacent strings can appear in many different formats – as this string table shows:

char *array[] = {
    "str_1",
    "str_2",
    "str_3"
    "str_4",
    "str_5",
    NULL};

Did you notice the missing comma (,) after "str_3"? It can be a hard one to spot.

This is the type of bug that can result in something like a simple parser failing:

if (strcmp(array[i], test_string) == 0)

because str_3 and str_4 will never be matched, but the others will.

The post Programming Error – Unintended String Concatenation appeared first on Complete, Concrete, Concise.

The switch keyword is probably the least well understood of the C/C++ language keywords (although, const probably comes a close second).

The keywords switch, case, and default always go together and cannot be used independently in any other context.

There is a small difference in behaviour between C and C++. Most programmers will never notice the difference.

The most common use of switch is as a replacement for multiple if-else statements:

                               switch (value)
                               {
if (value == 1)                   case 1:
{                                      ...
  ...                                 break;
} else if (value == 2)            case 2:
{                                      ...
  ...                                 break;
} else                            default:
{                                      ...
  ...                                 break;
}                              }

This usage is quite well understood. Its use as a jump table into a block of code is less well understood (and, to be honest, rarely used).

Format

switch ( controlling expression )
{
   case: constant expression  // optional
         .        .
         code statements
         .        .
         break;  // optional
   default:  //optional
         .        .
         code statements
         .        .
         break;  // optional
}

switch (controlling expression)

Every switch block must begin with the switch keyword. If you want a switch block then you have to use the switch keyword.

C and C++ differ in the way the controlling expression is handled.

In C the expression is converted to type int using C conversion rules. This means the controlling expression can be anything C knows how to convert to an int: the signed and unsigned varieties of char, short, int, long and long long as well as float, double, and long double.

In C++ the controlling expression must be an integral type – any of the signed or unsigned varieties of char, short, int, long, or long long – or any class, struct, or union for which there exists an unambiguous conversion to an integral type. Using a float, double, or long double is an error (unless, of course, you explicitly cast it to one of the integral types).

class A
{
 private:
    int value;
 public:
    operator int() {return value;} // conversion method
};

int main(void)
{
   A a;  // variable of type A above with conversion to int
   switch (a) // works because compiler calls operator int()
   {
      .
      .
      .
   }
   return 0;
}

operator char() {return char(value);}

A a;
int i;
char c;
short s;
i = a; // compiler calls operator int()
c = a; // compiler calls operator char();
s = a; // compiler cannot resolve between int() and char()

case (constant expression)

The constant expression is called a label or case label.

Unlike the controlling expression, the case label must be known at compile time – it cannot be a variable or in any other way determined at run time.

All case labels must be different. If two case labels resolve to the same value, then the program is malformed and the compile will fail.

// at one time, the following macros all had different values
// but at some point the difference between CONDITION_1 and
// CONDITION_2 was lost and they became the same.
// Most code will work just fine with this change, but not a
// switch block if it is using these labels.
#define CONDITION_1 0
#define CONDITION_2 0  // duplicated value
#define CONDITION_3 2
// instead of using macros, the conditions were encapsulated
// in an enum, but at some point the difference between CONDITION_1
// and CONDITION_2 was lost and they became the same.
// Most code will work just fine with this change, but not a
// switch block if it is using these labels.
enum Some_Values
{
   CONDITION_1 = 0,
   CONDITION_2 = 0, // duplicated value
   CONDITION_3 = 1
};
// when either the macros or enum values are used for the case
// labels, the program becomes malformed because two labels
// have the same value
switch (value)
{
   case CONDITION_1:
   case CONDITION_2: // compile will fail
   case CONDITION_3:
   default:
}

C and C++ differ in the way they handle the constant expression.

In C, the the expression is converted to type int. Both the controlling expression and constant expression are of type int.

In C++, the expression is converted to the type of the controlling expression. This means the constant expression is the same type as the controlling expression.

default

The default statement is where the switch operator jumps to if none of the case labels match the controlling expression.

Using switch for Multiway Selection

The switch statement is most commonly used when you want to choose one of several code paths and the decision is based on some sort of integer value (an enum is an integer at heart).

For simple choices, an if-else block works fine. But when you have many possible code paths to choose from, having a long chain of if-else statements can be unwieldy.

Consider a basic DVD player that responds to the following commands:

enum PLAYER_COMMANDS
{
   Off,
   On,
   Stop,
   Play,
   Pause,
   Eject
};

Implemented using if-else statements, the code would look like this:

if (command == Off)
{
   ... code ...
}
else if (command == On)
{
   ... code ...
}
... remaining else-if code ...
else
{
   printf("Error - unknown state\n");
}

Using a switch statement, the code would look like this:

switch (command)
{
   case Off:
      ... code ...;
      break;
   case On:
      ... code ...;
      break;
   ... remaining cases ...
   default:
      printf("Error - unknown state\n");
}

The switch block looks neater and more compact than the nested if-else code.

Order of case statements

The case and default statements inside the switch don’t have to be in any particular order. While not typical, it is perfectly valid to have the default statement at the top of the block (or in the middle of the block):

switch (controlling_expression)
{
   default: // not typical location, but perfectly legal
      ... some code ...
      break;
   case label_1:
      ... some code ...
     break;
};

Use of break

Usually, a break statement is placed at just before the next case (or default) statement.

Code execution stops at the break statement and continues at the next statement following the switch block.

If there is no break statement, then the code continues to be executed until either (1) a break statement is encountered, or (2) execution exits the switch block.

switch (controlling_expression)
{
   case label_1:
      ... some code 1 ...
   case label_2:
      ... some code 2 ...
      break;
   default:
      ... some code 3 ...
};

In the above example, if the controlling_expression switches to:

• label_1: then some code 1 will be executed. Since there is no break statement, execution will fall through and execute some code 2. Since there is a break after some code 2 code execution will continue at the next statement following the switch block.
• label_2: then some code 2 will be executed. Since there is a break statement, code execution will continue at the next statement following the switch block.
• default: then some code 3 will be executed. There is no break statement (it is optional for the last final label) because the next statement to be executed will be the one following the switch block.

Using Fall-through

Fall-through can be useful.

Unlike some other languages, C and C++ don’t allow a range of values for for a case label. For example, you could not write:

switch (month)
{
   case January ... July :
      ... some code ...
};

But, using fall-through, you can write code like this:

switch (month)
{
   case January:
   case March:
   case May:
   case July:
   case August:
   case October:
   case December:
      days = 31;
      break;
   case April:
   case June:
   case September:
   case November:
     days = 30;
     break;
   case February:
     days = 28;
};

In the above example, January falls through to the assignment days = 31;

Using switch as a Jump Table

A common complaint of programmers coming from other languages is that the switch in C and C++ is broken – it seems dumb to have to explicitly code a break to prevent fall-through in case statements. That’s because in most languages a switch or case block is compact way of selecting a block of code to execute. This is not the case in C and C++. In C and C++, the switch statement is not for selecting a block of code to execute, it is a jump table into a block of code.

Consider the following:

switch (control)
{
   default:
      printf ("Hello world!!!\n");
      printf ("Hello world!!!\n");
      printf ("Hello world!!!\n");
      printf ("Hello world!!!\n");
      printf ("Hello world!!!\n");
      printf ("Hello world!!!\n");
      printf ("Hello world!!!\n");
      printf ("Hello world!!!\n");
}

No matter what value control has, the 8 printf statements will be executed. We might as well not even have the switch statement to begin with. The code is, effectively, identical to 8 printf statements enclosed in their own block:

{
   printf ("Hello world!!!\n");
   printf ("Hello world!!!\n");
   printf ("Hello world!!!\n");
   printf ("Hello world!!!\n");
   printf ("Hello world!!!\n");
   printf ("Hello world!!!\n");
   printf ("Hello world!!!\n");
   printf ("Hello world!!!\n");
}

We could also write it this way:

goto DEFAULT: // whatever the value of control
{
DEFAULT:
      printf ("Hello world!!!\n");
      printf ("Hello world!!!\n");
      printf ("Hello world!!!\n");
      printf ("Hello world!!!\n");
      printf ("Hello world!!!\n");
      printf ("Hello world!!!\n");
      printf ("Hello world!!!\n");
      printf ("Hello world!!!\n");
}

Consider the following (which will print Hello World!!! either 1, 2, 3, 4, 5, or 8 times depending on the value of control):

switch (control)
{
   default:
      printf ("Hello world!!!\n");
      printf ("Hello world!!!\n");
      printf ("Hello world!!!\n");
   case 5:
      printf ("Hello world!!!\n");
   case 4:
      printf ("Hello world!!!\n");
   case 3:
      printf ("Hello world!!!\n");
   case 2:
      printf ("Hello world!!!\n");
   case 1:
      printf ("Hello world!!!\n");
}

It can be rewritten as:

if (control == 1) goto LABEL_1;
if (control == 2) goto LABEL_2;
if (control == 3) goto LABEL_3;
if (control == 4) goto LABEL_4;
if (control == 5) goto LABEL_5;
else goto DEFAULT;
{
DEFAULT:
      printf ("Hello world!!!\n");
      printf ("Hello world!!!\n");
      printf ("Hello world!!!\n");
LABEL_5:
      printf ("Hello world!!!\n");
LABEL_4:
      printf ("Hello world!!!\n");
LABEL_3:
      printf ("Hello world!!!\n");
LABEL_2:
      printf ("Hello world!!!\n");
LABEL_1:
      printf ("Hello world!!!\n");
}

It should be obvious that a switch block is a constrained goto where you can jump to any line inside the block via an appropriate case label.

do
{
   x = x + 2;
}
while (x < 100);

DO:
{
   x = x + 2;
}
if (x < 100) goto DO;

Knowing this helps to understand some of the “weird” behaviour of the switch statement in C and C++.

Fall-through

Fall through occurs because we do not select a block of code to execute, but jump to a line of code (within the block) and continue execution from there.

The break at the end of what we want to execute is simply a goto to the end of the block.

 case A of
   0: writeln('nothing');
   1: writeln('number 1');
   2: writeln('number 2');
   else writeln('big number');
 end;

if A = 0 then goto ZERO;
if A = 1 then goto ONE;
if A = 2 then goto TWO else goto BIG;
ZERO:
   writeln('nothing');
   goto CONTINUE;
ONE:
   1: writeln('number 1');
   goto CONTINUE;
TWO:
   2: writeln('number 2');
   goto CONTINUE;
BIG:
   writeln('big number');
CONTINUE:

Initialization Errors

It is common to want to use some local variables in a case label. Unfortunately, doing so can generate a compile time error that the variable has not been initialized:

switch (value)
{
   int a = 7;
   case 1:
       printf("%d\n", a);
       break;
   default:
       printf("%d\n", a * a);
}

In this example, when the code jumps to case 1 or default it bypasses the initialization of a.

Jumping into the middle of and embedded switch

Since a switch statement allows you to jump to an arbitrary point in a block of code, it is reasonable to ask if it is possible to jump into the middle of a nested switch block:

switch (value)
{
   case LABEL_1:
      switch (value_2)
      {
         case OTHER_LABEL_1:
            ... code ...
            break;
         case LABEL_2:  // can switch (value) jump here?
            ... code ...
            break;
      }
   case LABEL_3:
      ... code ...
      break;
}

The answer is no. This is because scope and visibility rules don’t allow value of the first switch to be seen inside of the nested switch block.

The following should make this clear:

int A = 7; // this is the outer_A
{   // start a new block
   int A = 3; // this is the inner_A
  // inside this block, the value of the outer_A is not visible
  // (ok, in C++ you could use the :: scope resolution operator
  //  to see the outer_A, but that is not the point)
}

In a similar way, the value of the controlling expression in the outer switch is hidden by the value of the controlling expression of the nested switch. This means the outer controlling expression has no scope within the nested switch, so it cannot jump into the middle of a nested switch.

The post Keyword – switch, case, default appeared first on Complete, Concrete, Concise.

Comments are an important part of documenting your code.

Adding comments to macros is quite easy, but it has to be done the right way.

This works with both C and C++ compilers.

The easiest way to document macros is to just add comments before or after the macro definition:

// returns the larger of the two arguments
#define MAX(x, y) (x)>(y)?(x):(y)

This works well for small macros, but if you have a larger macro that is spread over several lines, it might be nice to put comments nearer some tricky or crucial bit of code. You can do that by using C-style comments (/**/). The preprocessor treats comments as white space, so comments of the form /* some sort of comment */ are treated as white space.

#define TRANS_TEST(a, b, c) \
{   /* variables to store intermediate results*/ \
    bool aGb = false;\
    bool bGc = false;\
    if (a > b) \
    {\
        aGb = true;
        printf("'a' is larger than 'b'\n");\
    }\
    if (b > c) \
    {\
        bGc = true;
        printf("'b' is larger than 'c'\n");\
    }\
    /* do the transitivity test */ \
    if (aGb &&  bGc) \
    {\
        printf("by transitivity we know 'a' is larger than 'c'\n");\
    }\
}

The above (contrived) example, determines if parameter a is greater than parameter c by using the principle of transitivity.

C style comments were used to document the code. Note the line splicing (\) operator appears at the end of each line.

When this code is compiled, the preprocessor will treat the comment (and any white space surrounding it) as white space.

NOTE: Using C++ single line comments (//)won’t work because everything following the // until the end of the line is considered white space. Even if the macro is spread over several lines using the line splicing (\) operator, the preprocessor turns it into a single line and everything following the // will be considered part of the comment (hence, white space).

#define TRANS_TEST(a, b, c) \
{   // variables to store intermediate results \
    bool aGb = false;\
    bool bGc = false;\
    if (a > b) \
    {\
        aGb = true;
        printf("'a' is larger than 'b'\n");\
    }\
    if (b > c) \
    {\
       bGc = true;
       printf("'b' is larger than 'c'\n");\
    }\
    // do the transitivity test  \
    if (aGb &&  bGc) \
    {\
        printf("by transitivity we know 'a' is larger than 'c'\n");\
    }\
}

In the above example, the C++ single line comment was used. When it is processed by the preprocessor, everything until the end of the line (after all the lines have been spliced together) will be considered a comment. Consequently, the compiler will issue an error because all it will see is:

#define TRANS_TEST(a, b, c) {

The post How to Add Comments to Macros appeared first on Complete, Concrete, Concise.

Purpose

The #error directive terminates compilation and outputs the text following the directive.

Format

#error text

All preprocessor directives begin with the # symbol. It must be the first character on the line or the first character on the line following optional white space.

Spaces or tabs are permitted between the # and error, but not escape characters or other symbols or macros. The preprocessor removes white space and concatenates the # and error together.

If anything follows the #error directive (other than white space) then the program is malformed.

The following are valid uses:

#error some error message text
# error some error text to display
# /* comments are white space */ error some error message to display

The following are invalid uses:

// #\ is not a valid preprocessor directive
# \t error text to output
// #" is not a valid preprocessor directive
# "" text to output

Use

It is used to render a program malformed and output the text following the #error directive. The text may be quoted or unquoted (it doesn’t matter). No macro expansion takes place.

There are many times when it is useful to halt compilation:

1. code is incomplete
2. code requires particular library versions
3. code uses compiler dependent features
4. code has specific compiler requirements

Incomplete Code

When developing code, it is common to create stub functions. For the final release, these stub functions need to be implemented. We can let the compiler help us catch unimplemented functions:

int my_function( void )
{
 #error my_function not implemented
 return 0;
}

The above code will fail for every compile. It might be more useful to allow compiling during development, but break the compile when we try to compile a release version. In the following example, we assume that during development, the macro DEBUG is defined:

int my_function( void )
{
#ifndef DEBUG
 #error my_function not implemented
#endif
 return 0;
}

During development, we can compile the code, but when we do a release build (one in which DEBUG is not defined, then we catch unimplemented functions.

Version Checking

Sometimes code is dependent on particular versions of a library. It is useful to be able to stop compilation if an incorrect library version is included:

#if library_version < 2
#error requires library_version 2 or better
#endif

Compiler Dependency

Sometimes, code uses compiler specific features (for example, GCC allows nesting a #define within another #define – this is a non-standard compiler feature).

#ifdef __GCC__
// some GCC specific code goes here
#else
#error requires GCC compiler to compile
#endif

Compiler Requirements

Sometimes code makes relies on certain assumptions about the target environment (for example, the size of an integer):

#include 
#if UINT_MAX != 4294967295
 #error this application requires 32 bit integers
#endif

The post Preprocessor – the #error Directive appeared first on Complete, Concrete, Concise.

I don’t think I have ever seen this directive used.

Behaviour of this preprocessor directive is the same for both C and C++ compilers.

Purpose

The #line directive allows setting the current line number and name of the file being compiled.

Format

#line integer

or
#line integer "file_name"
or
#line preprocessing_expression

All preprocessor directives begin with the # symbol. It must be the first character on the line or the first character on the line following optional white space.

Spaces or tabs are permitted between the # and line, but not escape characters or other symbols or macros. The preprocessor removes white space and concatenates the # and line together.

If anything follows the #line directive (other than white space) then the program is malformed.

The following are valid uses:

#line 100
# line   100
# /* comments are white space */ line 100

The following are invalid uses:

// #\ is not a valid preprocessor directive
# \t line 100
// #" is not a valid preprocessor directive
# "" line 100

Use

There are three different forms of the #line directive which allow you to change the current line numbering and file name during preprocessing.

First Form – #line integer

When the line number is changed, the line immediately following the #line directive receives the new line number:

#line 123
/* this line is now line number 123 */
/* this line is line number 124 */
/* this line is line number 126 */

Second Form – #line integer file_name

When file_name is specified, the working name of the file being compiled is changed to the specified string. The file_name must be enclosed by double quotes (").

In the following example, the line number remains the same but the name of the file being compiled is changed to new_file_name.abc. Only the name the compiler thinks it is compiling changes (and which it will return using the __FILE__ macro), the actual (physical) file name remains the same:

#line __LINE__ "new_file_name.abc"

Third Form – #line preprocessor_tokens

The final form of the #line directive allows you to specify preprocessor tokens to be expanded. After expansion, the third form must look like one of the first two forms. If it does not, the program is malformed. NOTE: the preprocessor tokens are expanded, but not evaluated.

#define LINE_NUMBER 100
#define FILE_NAME(f) #f

#line LINE_NUMBER FILE_NAME(abc.h)

In the above example, LINE_NUMBER is expanded to 100 and FILE_NAME stringizes the passed parameter.

After compilation, the next line will be line number 100 and the name of the file being compiled will be abc.h.

The post Preprocessor – the #line Directive appeared first on Complete, Concrete, Concise.

Behaviour of this preprocessor directive is the same for both C and C++ compilers.
Behaviour of this directive is very likely to vary from one compiler vendor to another.

Purpose

The #pragma directive allows implementation specific control of the compiler.

Format

All preprocessor directives begin with the # symbol. It must be the first character on the line or the first character on the line following optional white space.

Spaces or tabs are permitted between the # and pragma, but not escape characters or other symbols or macros. The preprocessor removes white space and concatenates the # and pragma together.

If anything follows the #pragma directive (other than white space) then the program is malformed.

The following are valid uses:

#pragma pack(2)
# pragma once
# /* comments are white space */ pragma long_calls

The following are invalid uses:

// #\ is not a valid preprocessor directive
# \t pragma pack(2)
// #" is not a valid preprocessor directive
# "" pragma once

Use

All #pragma commands are compiler specific, so you need to consult your compiler documentation for details.

If the #pragma command is not recognized, the preprocessor ignores it.

Pragmas are used to pass information to the compiler that cannot be done through the language.

A common use of pragmas is to specify the packing / alignment of data. Normally, a compiler will align data on the processor’s natural boundary (which is usually the same as the processor’s bit size). However, for structures with byte defined data, 8-bit alignment may be required. The following shows byte alignment packing using Microsoft C/C++:

#pragma pack(push) /* save the current packing value */
#pragma pack(1) /* pack on a 1 byte boundary */
struct some_type_with_8_bit_alignment
{
char a;
short b;
long c;
char d;
};
#pragma pack(pop) /* restore the saved packing value */

The post Preprocessor – the #pragma Directive appeared first on Complete, Concrete, Concise.

This is one of three preprocessor operators. The other two operators are the token pasting operator (##) and the define operator.

The behaviour is the same for both C and C++ compilers.

Purpose

The stringizing operator is used to convert parameters passed to a macro into strings.

Format

# token_to_turn_into_a_string

Use

The stringizing (#) operator may only be used with #define preprocessor directives taking a parameter.

The parameter token immediately to the right of the stringizing operator (ignoring any white space) is transformed by the preprocessor into a string.

For example:

#define make_string(x) #x

will convert whatever is passed as parameter x into a string.

Leading and trailing white space are deleted.

Any white space between the parameter’s tokens are collapsed into a single white space character between tokens.

Any conversions necessary to make character literals in the parameter’s tokens valid in a string are automatically made. This means that characters like: \ and " are automatically converted to \\ and \" respectively.

If the token is a macro, the macro is not expanded – the macro name is converted into a string. As a consequence, some characters cannot be stringized – notably, the comma (,) because it is used to delimit parameters and the right parenthesis ()) because it marks the end of the parameter list.

Examples

Given the following macros:

#define make_string(x) #x
#define COMMA ,

the following uses:

make_string(twas brillig);
make_string( twas brillig );
make_string("twas" "brillig");
make_string(twas COMMA brillig);

get expanded into:

// no surprise here
"twas brillig"
// leading and trailing spaces were trimmed,
// space between words was compressed to a single space character
"twas brillig"
// the quotes were automatically converted
"\"twas\" \"brillig\""
// the macro COMMA was not expanded
"twas COMMA brillig"

#define make_string(...) # __VA_ARGS__

Stringizing a Single Character

Sometimes you want to create a character literal. Unfortunately, the language does not specify a charizing operator (although, the Microsoft compiler does provide the non-standard operator #@ for charizing a single character).

However, you can simulate a charizing operator as follows:

#define CHARIZE(x) #x[0]

What this does is stringize whatever is passed as parameter x and then addresses the first character – effectively acting as though the parameter had been charized. This works in most places a character literal is expected, but not all.

The post Preprocessor – Understanding the stringizing (#) Operator appeared first on Complete, Concrete, Concise.

Behaviour of this preprocessor directive is the same for both C and C++ compilers.

Purpose

The #endif directive is used end / close / terminate a selection block (#if, #ifdef, or #ifndef.

Format

All preprocessor directives begin with the # symbol. It must be the first character on the line or the first character on the line following optional white space.

Spaces or tabs are permitted between the # and endif, but not escape characters or other symbols or macros. The preprocessor removes white space and concatenates the # and endif together.

If anything follows the #endif directive (other than white space) then the program is malformed.

The following are valid uses:

#endif
#   endif
# /* comments are white space */ endif

The following are invalid uses:

// #\ is not a valid preprocessor directive
# \t endif
// #" is not a valid preprocessor directive
# "" endif
// malformed because only white space may follow #endif
#endif MY_MACRO

Use

The #endif must appear as the final statement of a preprocessor selection sequence.

#ifdef MY_MACRO
.
.
.
// preprocessor or language statements
.
.
.
#endif

The post Preprocessor – the #endif Directive appeared first on Complete, Concrete, Concise.

#else is one of five preprocessor selection statements allowing selection of alternative sections of code for compilation. The other four selection statements are: #ifdef, #ifndef, #if, and #elif.

Behaviour of this preprocessor directive is the same for both C and C++ compilers.

Purpose

The #else directive provides a final alternative for a preprocessor selection block. If all previous selection options fail, then the code found between the #else and #endif is compiled.

Format

All preprocessor directives begin with the # symbol. It must be the first character on the line or the first character on the line following optional white space.

Spaces or tabs are permitted between the # and else, but not escape characters or other symbols or macros. The preprocessor removes white space and concatenates the # and else together.

If anything follows the #else directive (other than white space) then the program is malformed.

The following are valid uses:

#else
#   else
# /* comments are white space */ else

The following are invalid uses:

// #\ is not a valid preprocessor directive
# \t else
// #" is not a valid preprocessor directive
# "" else
// malformed because only white space may follow #else
#else MY_MACRO

Use

The #else must appear as the last alternative in a preprocessor selection block. If all the preceding selection options fail, then the code contained between the #else and closing #endif is compiled.

The statements following the #else may be language statements or preprocessor statements. There is no limit on the nesting of preprocessor directives or statements.

 #ifdef MY_MACRO
.
.
.
// these statements will only be compiled if MY_MACRO exists
.
.
.
#else
.
.
.
// these statements will only be compiled if MY_MACRO does not exist
.
.
.
#endif

The post Preprocessor – the #else Directive appeared first on Complete, Concrete, Concise.

Behaviour of the #ifndef directive is the same in both C and C++.

Purpose

The #ifndef directive is one of five preprocessor selection statements allowing selection of alternative sections of code for compilation. The other four selection statements are: #ifdef, #if, #elif, and #else.

Format

All preprocessor directives begin with the # symbol. It must be the first character on the line or the first character on the line following optional white space.

Spaces or tabs are permitted between the # and ifndef, but not escape characters or other symbols or macros. The preprocessor removes white space and concatenates the # and ifndef together.

The following are valid uses:

#ifndef my_macro
# ifndef my_macro;
# ifndef my_macro
# /* comments are white space */ ifndef my_macro

The following are invalid uses:

// #\ is not a valid preprocessor directive
# \t ifndef my_macro
// #" is not a valid preprocessor directive
# "" ifndef my_macro

Use

If the macro name does not exist, then the statements following #ifndef until the end of the block (#endif, #else or #elif) are compiled.

If the macro name exists, then the statements following #ifndef until the end of the block (#endif, #else or #elif) are skipped (not compiled).

Since the code is conditionally compiled, it is possible the code never gets compiled and, as a consequence, any errors in it are never caught or noticed.

The simplest preprocessor selection block consists of just an #ifndef and a terminating #endif statement.

More complex selection blocks consist of an #ifndef followed by one or more #elif and / or a final #else statement.

Any valid preprocessor statements, including other #ifndef statements, may be part of the code in the selection block. There is no limit on the level of nesting of selection statements.

The following:

#ifndef my_macro

is equivalent to:

#if !defined my_macro

This directive is most commonly used to prevent multiple inclusion of header files:

#ifndef my_header
#define my_header
.
.
.
// contents of the header file
.
.
.
#endif

The post Preprocessor – the #ifndef Directive appeared first on Complete, Concrete, Concise.

This (along with the #if directive) is probably the second most complicated preprocessor directive because the controlling expression can be complex and include tricky macro replacements.

#elif is one of five preprocessor selection statements allowing selection of alternative sections of code for compilation. The other four selection statements are: #ifdef, #ifndef, #if, and #else.

Behaviour of this preprocessor directive is the same for both C and C++ compilers.

An identifier is a sequence of letters, numbers and underscore characters. Identifiers must begin with a letter or underscore character.

Purpose

The #elif directive controls whether the statements found between it and a terminating #endif, #else, or #elif directive are compiled or skipped. The decision is based on the value of the controlling expression.

It is used to allow creating more complex code selection blocks, featuring more alternatives.

Format

All preprocessor directives begin with the # symbol. It must be the first character on the line or the first character on the line following optional white space.

Spaces or tabs are permitted between the # and elif, but not escape characters or other symbols or macros. The preprocessor removes white space and concatenates the # and elif together.

The following are valid uses:

#elif defined my_macro
# elif defined my_macro;
# elif defined my_macro
# /* comments are white space */ elif defined my_macro

The following are invalid uses:

// #\ is not a valid preprocessor directive
# \t elif defined my_macro
// #" is not a valid preprocessor directive
# "" elif defined my_macro

Rules for the Controlling Expression

The controlling_expression must be made up of: integers, identifiers, macros, character literals, operators, or the preprocessor operator defined. Strings, floating point values, preprocessor directives, the token pasting operator (##), and stringizing operator (#) are invalid and the program is malformed.

The controlling_expression must evaluate to an integer value.

If the controlling expression is non-zero (TRUE), then the statements following the #elif until the end of the block (#endif, #elif, or #else) are compiled.

 #if 0
.
.
.
// because the controlling expression is zero (FALSE) everything
// until the end of the current block (#elif 42) will be skipped
.
.
.
#elif 42
.
.
.
// because everything in the first block was skipped, and this
// controlling expression evaluates to non-zero (TRUE), all the
// statements until the end of the current block (#else) will be
// compiled.
.
.
.
#else
.
.
.
// all the statements here are skipped because the statements in
// the previous block were compiled
.
.
.
#endif

If the controlling expression is zero (FALSE), then the statements following the #elif until the end of the block (#endif, #elif, or #else) are skipped.

Integers can be signed or unsigned and have a minimum range equal to long and unsigned long integers, respectively.

Identifiers that are macro names are expanded and evaluated and their evaluation value replaces the macro name.

If the macro name is evaluated by the defined operator, then it is not expanded:

#define MY_MACRO "twas brillig"
// MY_MACRO will never be expanded or evaluated.
// the defined operator determines if the identifier MY_MACRO
// exists. It returns 1 if the macro is defined or 0 if the macro is
// not defined.
#if 0
// everything in here is skipped
#elif defined MY_MACRO
// code in here will only be compiled if MY_MACRO exists
#endif

Identifiers that are not macro names, are replaced with a value of 0 (zero):

#elif SOME_RANDOM_IDENTIFIER

If the identifier SOME_RANDOM_IDENTIFIER was never defined using #define or was undefined (before its use) using #undef, then it is assigned the value of 0 (zero). To the preprocessor, it looks like:

#elif 0

Character literals are converted into integer values. The value of a character literal appearing in either #if or #elif does not have to be the same as the value a character literal would have in a code expression. This is because the character set used by the preprocessor does not have to be the same as the character set used by the compiler.

Depending on the compiler, character literals may or may not be permitted to have negative values.

Any of the arithmetic, relational, logical, or bitwise operators may be used in the controlling_expression. Evaluation precedence is the same as for the language.

#elif never begins a selection block, it is always used as an alternative selection following a previous #if, #ifdef, #ifndef, or #elif preprocessor directive.

The post Preprocessor – the #elif Directive appeared first on Complete, Concrete, Concise.

This (along with the #elif directive) is probably the second most complicated preprocessor directive because the controlling expression can be complex and include tricky macro replacements.

#if is one of five preprocessor selection statements allowing selection of alternative sections of code for compilation. The other four selection statements are: #ifdef, #ifndef, #elif, and #else.

Behaviour of this preprocessor directive is the same for both C and C++ compilers.

An identifier is a sequence of letters, numbers and underscore characters. Identifiers must begin with a letter or underscore character.

Purpose

The #if directive controls whether the statements found between it and a terminating #endif, #else, or #elif directive are compiled or skipped. The decision is based on the value of the controlling expression.

Format

All preprocessor directives begin with the # symbol. It must be the first character on the line or the first character on the line following optional white space.

Spaces or tabs are permitted between the # and if, but not escape characters or other symbols or macros. The preprocessor removes white space and concatenates the # and if together.

The following are valid uses:

#if defined my_macro
# if defined my_macro;
# if     defined    my_macro
# /* comments are white space */ if defined my_macro

The following are invalid uses:

// #\ is not a valid preprocessor directive
# \t if defined my_macro
// #" is not a valid preprocessor directive
# "" if defined my_macro

Rules for the Controlling Expression

The controlling_expression must be made up of: integers, identifiers, macros, character literals, operators, or the preprocessor operator defined. Strings, floating point values, preprocessor directives, the token pasting operator (##), and stringizing operator (#) are invalid and the program is malformed.

The controlling_expression must evaluate to an integer value.

If the controlling expression is non-zero (TRUE), then the statements following the #if until the end of the block (#endif, #elif, or #else) are compiled.

 #if 3
.
.
.
// because the controlling expression is non-zero (TRUE) everything
// until the end of the current block (#elif 42) will be compiled
.
.
.
#elif 42
.
.
.
// everything in here is skipped because the statements in the first
// block were compiled
.
.
.
#else
.
.
.
// all the statements here are skipped because the statements in the
// first block were compiled
.
.
.
#endif

If the controlling expression is zero (FALSE), then the statements following the #if until the end of the block (#endif, #elif, or #else) are skipped.

Integers can be signed or unsigned and have a minimum range equal to long and unsigned long integers, respectively.

Identifiers that are macro names are expanded and evaluated and their evaluation value replaces the macro name.

If the macro name is evaluated by the defined operator, then it is not expanded:

#define MY_MACRO "twas brillig"
// MY_MACRO will never be expanded or evaluated.
// the defined operator determines if the identifier MY_MACRO
// exists. It returns 1 if the macro is defined or 0 if the macro is
// not defined.
#if defined MY_MACRO

Identifiers that are not macro names, are replaced with a value of 0 (zero):

#if SOME_RANDOM_IDENTIFIER

If the identifier SOME_RANDOM_IDENTIFIER was never defined using #define or was undefined using #undef, then it is assigned the value of 0 (zero). To the preprocessor, it looks like:

#if 0

Character literals are converted into integer values. The value of a character literal appearing in either #if or #elif does not have to be the same as the value a character literal would have in a code expression. This is because the character set used by the preprocessor does not have to be the same as the character set used by the compiler.

Depending on the compiler, character literals may or may not be permitted to have negative values.

Any of the arithmetic, relational, logical, or bitwise operators may be used in the controlling_expression. Evaluation precedence is the same as for the language.

The controlling expression may be a simple or complex:

// a simple controlling expression
#if    3

// a more complex controlling expression
#if ( MY_IDENTIFIER > 7 ) && ( VERSION >= 3 )

Since the code is conditionally compiled, it is possible the code never gets compiled and, as a consequence, any errors in it are never caught or noticed.

Any valid language or preprocessor statements may occur within the selection block – even other #if statements. There is no restriction on the level of nesting permitted.

The following:

#if defined MY_MACRO

is equivalent to:

#ifdef MY_MACRO

The following:

#if !defined MY_MACRO

is equivalent to:

#ifndef MY_MACRO

The following:

#if defined MY_MACRO && defined MY_OTHER_MACRO

is equivalent to:

#ifdef MY_MACRO
#  ifdef MY_OTHER_MACRO

The post Preprocessor – the #if Directive appeared first on Complete, Concrete, Concise.