Programming Archives - Complete, Concrete, Concise

5 Minute Vim Tutorial

richardsplanet — Wed, 26 Oct 2016 18:11:54 +0000

Vim works differently from other editors you are used to, but it only takes about 5 minutes to learn the basics you need to edit with Vim. You won’t be a Vim wizard, but you will be able to:

Open a file
Move around in a file
Edit text in a file
Save a File

The slightly longer Extended 5 Minute Tutorial you will show you how to search in a file, get help, and access Vim’s own built-in tutorial.

Vim in 5 Minutes (or less)
The Extended 5+ Minute Tutorial
Final Words

Vim in 5 Minutes (or less)

Vim operates in Modes. Vim always starts in Normal Mode.
Normal Mode is your base mode and you should always return to it.
All command / control keys are case sensitive.
If you are not in Normal Mode, you (usually) get back to Normal Mode by pressing the Escape key twice.
If you see recording in the lower left corner of the screen, press the q key to return to Normal Mode.
If you’ve messed stuff up, return to Normal Mode and type :q! followed by the Enter key to exit Vim without saving the file.
In Normal Mode you can navigate the file using the h, j, k, l keys (left, down, up, right). You might also be able to use the arrow keys on the keyboard¹.
When you have navigated to where you want to edit the file (inserting or deleting text), press the i key to enter Insert Mode.
In Insert Mode you can only enter or delete text from the current cursor position – you cannot navigate. To navigate, press the Escape key to return to Normal Mode.
To save (write) the file, return to Normal Mode and type :w followed by the Enter key.
To exit (quit) Vim, return to Normal Mode and type :q followed by the Enter key.

The Extended 5 Minute Tutorial

This adds searching and help to the 5 Minute Tutorial, but, otherwise, keeps the information to the bare minimum so you can quickly be functional in Vim instead of frustrated.
All command / control keys are case sensitive: h is not the same as H!

Normal Mode

Normal Mode is the default mode and it should be the mode you always go back to.
Most times, you press the Escape key once or twice² to return to Normal Mode.
If you see recording in the lower left corner of the screen, press the lowercase q key to return to Normal Mode.

Opening a File

The simplest way to open a file is to type vim at the command line followed by the name of the file:

user@COMPUTER:~$ vim file.txt

If it is a new file you should see something like this:


~
~
~
~
~
"file.txt" [New File]                       0,0-1          All

If it is an existing file, you should see something like this:



  
    
    Basic HTML5 Template
    
  
  
    
    This is some dummy content that is not lorem ipsum.
  

~
~
~
"basic.html" 12L, 290C                      1,1           All

The status line³ (at the bottom of the screen) displays the following information:

file name
total number of lines in the file
total number of characters in the file
current line the cursor is on
current column the cursor is in
percentage showing the position in the file (if All : the entire file is visible, Bot : at the bottom (end) of the file, Top : at the top of the file)

In Normal Mode load a file by typing :edit followed by the filename and then pressing the Enter key.:

:edit basic.html

This discards the current file (if any) and loads the specified file.
If the file to be discarded has been modified, but not saved, you will see the following warning in the status line:

E37: No write since last change (add ! to override)

If you don’t care about saving the file, simply append ! to the :edit command:

:edit! basic.html

The ! tells Vim to “just do it!” and ignore any warnings.

Saving a File

You need to be in Normal Mode to save a file.
Save a file by typing :w followed by the Enter key.
If you want to save the file with a different name, type :w followed by the new file name and then press the Enter key:

:w new-filename.txt

Exiting Vim

You need to be in Normal Mode to exit Vim.
Type :q followed by the Enter key to exit Vim.
If Vim warns you that the file has been modified, you can choose to save it or you can force Vim to exit without saving the file by typing :q! followed by the Enter key. The ! tells Vim to “just do it” and exit without saving the file.

Navigating a File {Navigating}

You need to be in Normal Mode to navigate a file.
The letters h, j, k, l navigate the cursor through the file. (You may also be able to use the arrow keys present on most keyboards.)
They act like arrow keys and are conceptually laid out like this:

h
←

j
↓

k
↑

l
→

When you navigate left (h) to the beginning of a line, the cursor will stop. It will not wrap around and up to the previous line.
When you navigate right (l) to the end of a line, the cursor will stop. It will not wrap around and down to the next line.
If you type a positive integer (which will not be displayed), followed by one of the navigation keys, the cursor will move that many characters / lines.
For example, in Normal Mode, if you type 10j, the cursor will move down 10 lines.

Inserting and Deleting Text

In Insert Mode the only thing you can do is insert or delete text. (You may be able to use the arrow keys on your keyboard to navigate the text while in this mode, but there is no guarantee, navigating is supposed to be done in Normal Mode)
Enter Insert Mode by pressing the i, a, I, or A key.

i insert / delete before the cursor (what you would intuitively expect when entering or deleting text).
a append / delete after the current cursor position.
I insert / delete at the beginning of the line.
A append / delete at the end of the line.

You will (probably) be using i most frequently.
When you enter Insert Mode you will see – INSERT – displayed in the lower left corner:

The navigation keys are h, j, k, l.
h moves the̲ cursor one character left
l moves the cursor one character right
j moves the cursor one line down
k moves the cursor one line up
~
~
~
~
-- INSERT --                       3,11      All

Press the Escape key to return to Normal Mode.

Searching

You must be in Normal Mode to search.
In a large file, it is useful to locate items of interest by searching for them.
To search, type / followed by the text you want to find, followed by the Enter key.
Vim treats the search string as a regular expression – which means some characters have a special meaning. If you need to search for the following characters, you will need to type them as follows:

Name	Character	Need to Type
Period	.	.
Asterisk	*	\*
Backslash		\
Dollar Sign	$	$
Forward Slash	/	/

Searches are case sensitive.
You can navigate between search results by pressing n (next) or N (previous).

Getting Help

You need to be in Normal Mode to use help.
To get help on something in Vim, simply type :help followed by the thing you want help on.
For example, to get help on the navigation key h, type :help h followed by the Enter key.
You should see something similar to the following:

h         or          *h*
    or          **
CTRL-H    or          *CTRL-H* **
      [count] characters to the left.  |exclusive| motion.
          Note: If you prefer  to delete a character, use
          the mapping:
             :map CTRL-V    X
          (to enter "CTRL-V" type the CTRL-V key, followed
          by the  key)
          See |:fixdel| if the  key does not do what you
          want.
m̲o̲t̲i̲o̲n̲.̲t̲x̲t̲ ̲[̲H̲e̲l̲p̲]̲[̲R̲O̲]̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲1̲7̲2̲,̲1̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲1̲2̲%̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲
Vim will split the display into two panes. In the upper pane
you will see the help text. In the lower pane you will see your
current editing buffer.
Now you know that Vim supports multiple editing buffers - but
that is not the point of this tutorial.
~
~
~
~
a-file.txt                     4,5              All

The help can be pretty dense and not user friendly, but it may be helpful.
To close the help window, type :q followed by the Enter key.
If you type :help, it will bring up the general help file. You can navigate through it for topics of interest.
You might also try :help tutor for instructions on accessing the Vim tutor which is included with every Vim installation.

Final Words

Vim may not be the easiest or most intuitive editor you will come across. However, it (or its ancestor Vi) is quite ubiquitous and this tutorial gives you the basics you need so you are minimally functional with it.
The basics are simple:

Vim operates in Modes.
All command / control keys are case sensitive : k is not the same as K.
The base mode is Normal Mode. You (usually) get back to it by pressing the Escape key once or twice.
Navigating a file is done in Normal Mode using the h, j, k, l keys.
When the cursor is where you want to insert or delete text, you press the i key to enter Insert Mode.
Search in Normal Mode by typing / followed by the string you want to find and then the Enter key. Navigate the search results using the n and N keys.
Save a file by typing :w in Normal Mode.
Exit Vim by typing :q in Normal Mode.
In Normal Mode you can get help by typing :help

Vi (the precursor to Vim) was developed in 1976. Arrow keys were not commonly found on keyboards, so h, j, k, l were used.↩
Some modes require one key press, others require two. If you press it too many times, the computer will just beep at you. Vim newbies often repeatedly press the Escape key in the hopes of returning to Normal Mode↩
This is true for the default Status Line. It is always possible that someone has modified the Status Line to display different information, or in a different arrangement.↩

The post 5 Minute Vim Tutorial appeared first on Complete, Concrete, Concise.

Using FLTK with Code::Blocks

richardsplanet — Tue, 12 Nov 2013 20:12:22 +0000

FLTK is a easy to use, free GUI library.

While Code::Blocks provides a FLTK project option, the problem is that it doesn’t work correctly. This is because Code::Blocks expects the FLTK include directory to be somewhere else.

These instructions are for FLTK 1.3.2 and Code::Blocks 12.10 or Code::Blocks 13.12 running on Windows 7.

The instructions are probably the same for other version combinations, but no guarantee is made.

Assumes you have already built and installed the FLTK libraries.

When you try to create a FLTK project using Code::Blocks, after you enter your FLTK directory, you are presented with the following error message:

This occurs because the Code::Blocks wizard is pretty stupid and expects header files to be found in a /include directory. FLTK, puts its header files in the directory /FL.

The function at fault is GetCompilerIncludeDir found in the file common_functions.script located in the ..\CodeBlocks\templates\wizard directory.

Solution #1

Note: this does not work for Code::Blocks 13.12

This is the easiest solution, but it changes the FLTK directory structure – it also means you have file duplication (if you choose the copy option).

1) Create an include directory in your FLTK directory:

2) Copy (or move) the FL folder into the include directory.

Solution #2

A little more complicated, but preserves the FLTK directory structure.

This requires editing the FLTK wizard script.

1) Open the file wizard.script. This is located in the

..\CodeBlocks\share\CodeBlocks\templates\wizard\fltk directory.

If you used the standard Code::Blocks install, it is probably located in the C: drive at C:\Program Files (x86)\CodeBlocks\share\CodeBlocks\templates\wizard\fltk.

If the file is located in C:\Program Files (x86)... then you will probably have difficulty editing it because, as a security feature, Windows 7 (and other versions) prevent anyone other than an administrator from editing content in that directory.

You will need to open a file editor with administrator privileges to be able to edit the file.

Instructions on how to open a file editor with administrator privileges can be found here.

2) Locate FltkPathDefaultInc and change #fl.fl to #fl for the line :

For Code::Blocks 13.12, you change #fl.include to #fl.

3) Comment out (or delete) the entire function OnLeave_FltkPath(fwd) (you can use the standard C++ single line comment // to comment out each line):

4) Restart Code::Blocks (if Code::Blocks was open when you made these changes).

The post Using FLTK with Code::Blocks appeared first on Complete, Concrete, Concise.

warning: [options] bootstrap class path not set in conjunction with -source 1.5

richardsplanet — Wed, 03 Apr 2013 16:38:58 +0000

When compiling with Java, you may get a warning message similar (or identical to):

warning: [options] bootstrap class path not set in conjunction with -source 1.5

This warning is emitted if you are using JDK 7 Build 121 or later (earlier versions of the compiler would not issue a warning).

It is warning you that your Java compiler version and the version of Java you are compiling for are different. For example, you may have version 7 of the compiler installed, but are choosing to compile for Java version 5.0. While the compiler is capable of emitting code for different versions, it needs to use the correct startup libraries (bootstrap) in order to guarantee it will function correctly.

In any other language, this would be called “linking against the correct startup libraries”, but in Java, it is called “compiling against bootstrap and extension classes”.

For Users of NetBeans IDE

These instructions are for NetBeans IDE 7.3.

I suspect the instructions are the same for other versions of NetBeans IDE, but I make no guarantee.

You can correct the warning by ensuring the compiler version and binary version are the same:

1) Right-click on the project:

2) Select Properties:

3) Ensure that the Source/Binary Format: under the Sources category, matches the Java Platform under the Libraries category (click for full sized image):

For Command Line Users

If you are compiling using the command line, then you need to ensure that the -source and -target options refer to the same version and the -bootclasspath option refers to the correct Java runtime.

For example, if you have JDK 7 installed and want to compile for Java 5.0, then the command line would be:

javac -source 1.5 -target 1.5 -bootclasspath path-to-java-5.0-runtime code.java

Where path-to-java-5.0-runtime is the path to the rt.jar file of Java 5.0 (note: you have to include rt.jar as part of the path.

Where code.java is Java code compatible with version 5.0.

Note: The mapping from Java version to command line attributes are:

Java 1.2 => 1.3 (unless there is a typo in the JDK 7 warning, it is 1.3 not 1.2)
Java 1.3 => 1.3
Java 1.4 => 1.4
Java 5.0 => 1.5
Java 6 => 1.6

Normally, you do not have to specify the -target option because by default it is set the same as the -source option.

For Other IDE Users

You will have to read (or explore) your IDE to determine where the compiler and target settings are located. It is probably a safe bet that they are part of the project options (try right-clicking on the project name and see if a menu pops up, or see if there is something like a Project Options setting somewhere.

More Information

These are external links and where deemed to be safe and relevant at the time of publication.

If there are problems with them, please let me know.

javac – Java programming language compiler – search for bootclasspath on the page

Java SE 7 and JDK 7 Compatibility – a discussion about Java 7 compatibility with previous versions

The post warning: [options] bootstrap class path not set in conjunction with -source 1.5 appeared first on Complete, Concrete, Concise.

Programming Error – Unintended String Concatenation

richardsplanet — Tue, 19 Mar 2013 08:38:42 +0000

In an effort to be helpful, C and C++ compilers concatenate adjacent strings together.

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.

Keyword – switch, case, default

richardsplanet — Thu, 22 Mar 2012 06:56:52 +0000

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).

An “implicit” conversion from a class, struct or union to an integral type might seem new to some. Here is an example:

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

This can be used in a switch statement as follows:


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

In the above example, when an object of type A is used anywhere a type int is expected, the conversion operator int() will be called.

If we expand the class by adding another conversion operator to a different integral type, say

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

then it is no longer unambiguous because there are two integral types to choose from: int or char. The compile will fail because the compiler cannot resolve between the two integral types.

Conversions can be ambiguous in other types of code as well:

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)

case statements are optional – you don’t have to have any. But, you do need at least one case or default statement in your switch body.

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.

The two most common ways that case labels get the same value is through macros or enums:


// 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 optional – you don’t have to have one. But, you do need at least one case or default statement in your switch body.

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

This is the most common (and best understood) use of the switch statement.

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

This is the least commonly understood and used behaviour of the switch statement. Its most infamous example is Duff’s Device.

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.

There is no need to get alarmed, every control statement in every programming language that alters the flow of program execution is a constrained goto.

Consider a do-while loop:

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

This is identical to:

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.

Looked at another way, switch or case constructs in other languages do exactly the same thing, except that before the next label, they implicitly insert a goto to the end of the block.

Consider the following example in Pascal:

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

This is identical to:

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:

Notice the implicit gotos inserted to prevent fall-through.

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.

How to Add Comments to Macros

richardsplanet — Thu, 21 Jul 2011 01:34:12 +0000

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.

Preprocessor – the #error Directive

richardsplanet — Wed, 20 Jul 2011 08:04:02 +0000

Preprocessor – the #error Directive

This is a very useful and often underused preprocessor directive.

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

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.

Some early compilers flagged an error if # was not the first character on the line.

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.

The language specifications do not say how the text following the #error directive is to be treated.

The GCC compiler, replaces all white space characters between tokens with a single white space character.

I have no reason to believe other compilers behave differently since white space is not considered significant in the C and C++ languages – it serves only to seperate tokens from one another.

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

code is incomplete
code requires particular library versions
code uses compiler dependent features
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.

Preprocessor – the #line Directive

richardsplanet — Tue, 19 Jul 2011 13:46:30 +0000

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

#line integer "file_name"

#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.

Some early compilers flagged an error if # was not the first character on the line.

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 */

For C89/C90 and C++97, the valid range of values for the line number is from 1 to 32767 (0x0001 to 0x7FFF).

In C99 and the upcoming C++0x, the valid range of values for the line number is from 1 to 2147483648 (0x00000001 to 0x7FFFFFFF).

How the compiler deals with out of range values is undefined. Some compilers may accept them, others may issue a warning or error.

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.

NOTE: changing the line numbers and file names can cause grief when you try to debug your code.

Changing line numbers and the working file name can make debugging much harder.

When I used GCC to test the code, the debug information contained line numbering information and file name information that was different from what the IDE (in this case Code::Blocks) knew it to be. When I set breakpoints, Code::Blocks used the line and file name information it was aware of – which was different from what ended up in the debug information. I had to set the breakpoints manually for the “correct” line numbers and file name.

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

Preprocessor – the #pragma Directive

richardsplanet — Sun, 17 Jul 2011 19:07:22 +0000

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

#pragma command

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.

Some early compilers flagged an error if # was not the first character on the line.

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.

Preprocessor – Understanding the stringizing (#) Operator

richardsplanet — Sat, 16 Jul 2011 19:47:33 +0000

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"

In C99 and the upcoming C++0x languages, you can use a variadic macro to pass commas to the stringizing operator.

#define make_string(...) # __VA_ARGS__

Since __VA_ARGS__ does not process the comma separator, you can pass it to the stringizing operator. However, you still cannot pass the right parenthesis.

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.

Preprocessor – the #endif Directive

richardsplanet — Fri, 15 Jul 2011 22:40:58 +0000

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

#if or #ifdef or #ifndef

preprocessor or code statements

#elif controlling_expression (optional)

preprocessor or code statements

#else (optional)

preprocessor or code statements

#endif

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.

Some early compilers flagged an error if # was not the first character on the line.

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.

Preprocessor – the #else Directive

richardsplanet — Wed, 13 Jul 2011 17:39:51 +0000

#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

#if or #ifdef or #ifndef

preprocessor or code statements

#elif controlling_expression (optional)

preprocessor or code statements

#else

preprocessor or code statements

#endif

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.

Some early compilers flagged an error if # was not the first character on the line.

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.

Programming Archives - Complete, Concrete, Concise

5 Minute Vim Tutorial

Contents

Vim in 5 Minutes (or less)

The Extended 5 Minute Tutorial

Normal Mode

Opening a File

Saving a File

Exiting Vim

Navigating a File {Navigating}

Inserting and Deleting Text

Searching

Getting Help

Final Words

Using FLTK with Code::Blocks

Solution #1

Solution #2

warning: [options] bootstrap class path not set in conjunction with -source 1.5

For Users of NetBeans IDE

For Command Line Users

For Other IDE Users

More Information

Programming Error – Unintended String Concatenation

Keyword – switch, case, default

Format

switch (controlling expression)

case (constant expression)

default

Using switch for Multiway Selection

Order of case statements

Use of break

Using Fall-through

Using switch as a Jump Table

Fall-through

Initialization Errors

Jumping into the middle of and embedded switch

How to Add Comments to Macros

Preprocessor – the #error Directive

Purpose

Format

Use

Incomplete Code

Version Checking

Compiler Dependency

Compiler Requirements

Preprocessor – the #line Directive

Purpose

Format

Use

First Form – #line integer

Second Form – #line integer file_name

Third Form – #line preprocessor_tokens

Preprocessor – the #pragma Directive

Purpose

Format

Use

Preprocessor – Understanding the stringizing (#) Operator

Purpose

Format

Use

Examples

Stringizing a Single Character

Preprocessor – the #endif Directive

Purpose

Format

Use

Preprocessor – the #else Directive

Purpose

Format

Use