Indentation is very important as it improves the readability,maintainability of your programs dramatically.Consider this eg

if(i>=3)
if(j>=4)
if(k>=5)
m=6;

This is very difficult to read.Now consider this one
if(i>=3)
if(j>=4)
if(k>=5)
m=6;

This is now very easy to understand.There is no hard and fast rules about indentation as various organizations follow their own standards.But u should always be consistent,pick one style and stick to it.Normally we follow one tab to indent our code.My own examples sometimes don't follow that But please don't bother about it
Nowadays editors indent the code by themselves but u can customize it.

6.
Another Gem

a= b/*p ;//*p is the divisor

what will be the output of a? Common sense implies it should be the result of division of b and *p. But there's a catch which we are going to find out. Before proceeding, from the c reference manual
"‘‘If the input stream has been parsed into tokens up to a given character, the next token is taken to include the longest string of characters which could possibly constitute a token.’’ Thus, if a "/" is the first character of a token, and the / is immediately followed by a *, the two characters begin a comment, regardless of any other context. In fact, /*begins a comment, so the compiler will simply gobble up the program text until the */appears. In other words, the statement just sets a to the value of b and comments the rest and doesn't bother with p at all . Rewriting this statement as

a = b / *p ; //*p is the divisor, Note a white space between / and *

or even

a = b/(*p) ; //*p is the divisor

would cause it to do the division the comment suggests. But its always preferable to use the second version as it clearly indicates our preference.

Hehe.. you have an interesting style, but it's just easier to read with the spaces in between!

Yeah i agree,thanks for the feedback I will try to add some more spaces in the future topics

7.
Another C/C++ pearl

It would be a gross injustice in leaving any discussion of syntactic pitfalls without mentioning the Dangling else problem. Although it is not unique to C/C++, it has bitten C/C++ programmers with many years of experience.

Consider the following example:

if (a == 0)
if (b == 0)
//do something;
else {
m = a + b;
}
The programmer’s intention for this fragment is that there should be two main cases: a= 0 and a≠0. In the first case, the fragment should do nothing at all unless b = 0, in which case it should "do something". In the second case, the program should set m = a + b.
However, the program fragment actually does something quite different. The reason is the rule that an else is always associated with the closest unmatched if. If we were to indent this fragment the way it is actually executed, it would look like this:

if (a == 0) {
if (b == 0)
//do something;
else {
m = a + b;
}
}

In other words, nothing at all will happen if a≠0. To get the effect implied by the indentation of the original example, write:
if (a == 0) {
if (b == 0)
//do something;
} else {
m = a + b;

}

The indentation has been messed up,if u r confused feel free to raise questions and as always feed-backs are greatly appreciated.

use the code tags to show the indentation properly.

Thanks

8.

What will be the output of the above code on compilation?
The confusing part is the second statement
k=i+++j;
which can mean

both are valid syntax.According to C reference manual when we have more than one possibility for the next token the compiler will choose the longest one i.e. the statement will be treated as

So our output will be
k=3
i=2
j=2

If we need different evaluation we will need to supply parenthesis.Thank u grstanford for advising me to use the <code> tag.

9.
Ok it has been some time,i guess its time for another C/C++ gem


The output:-
I is greater than J
I is smaller than J
I is greater than J

First thing that comes to mind that my compiler may be faulty,how on earth can be "-1" greater than "1"?This is one of the very weird rules of C/C++. if u mix an unsigned and signed type the result is of the unsigned type.If u convert "-1" to a positive integer it becomes a huge number which is definitely greater than "1". The third "If...else" shows what is happening behind the scenes by means of a cast.Moral of the story ,never mix an unsigned and signed type.We tend to declare unsigned types for some variables which can't be negative for e.g. Age,but this is a bad choice.We should only declare unsigned types for bitfields (more on this later). Now cppcheck throws a waring when u compile this code,

warning C4018: '>' : signed/unsigned mismatch

It shows the static analyzers can be god sent at times if we look carefully at the warnings.