What's the purpose of using braces (i.e. {}) for a single-line if or loop?

Let's attempt to also modify i when we increment j:

int j = 0;for (int i = 0 ; i < 100 ; ++i)    if (i % 2 == 0)        j++;        i++;

Oh no! Coming from Python, this looks ok, but in fact it isn't, as it's equivalent to:

int j = 0;for (int i = 0 ; i < 100 ; ++i)    if (i % 2 == 0)        j++;i++;

Of course, this is a silly mistake, but one that even an experienced programmer could make.

Another very good reason is pointed out in ta.speot.is's answer.

A third one I can think of is nested if's:

if (cond1)   if (cond2)       doSomething();

Now, assume you now want to doSomethingElse() when cond1 is not met (new feature). So:

if (cond1)   if (cond2)       doSomething();else   doSomethingElse();

which is obviously wrong, since the else associates with the inner if.

Edit: Since this is getting some attention, I'll clarify my view. The question I was answering is:

What's the benefit of using the 1st version?

Which I have described. There are some benefits. But, IMO, "always" rules don't always apply. So I don't wholly support

Always use a { } block - even for a single line // not OK, why ???

I'm not saying always use a {} block. If it's a simple enough condition & behavior, don't. If you suspect someone might come in later & change your code to add functionality, do.

It's very easy to accidentally change control-flow with comments if you do not use { and }. For example:

if (condition)  do_something();else  do_something_else();must_always_do_this();

If you comment out do_something_else() with a single line comment, you'll end up with this:

if (condition)  do_something();else  //do_something_else();must_always_do_this();

It compiles, but must_always_do_this() isn't always called.

We had this issue in our code base, where someone had gone in to disable some functionality very quickly before release. Fortunately we caught it in code review.

I have my doubts as to the competence of the lecturer. Considering hispoints:

1. OK
2. Would anyone really write (or want to read) (b*b) - ((4*a)*c)?Some precedences are obvious (or should be), and the extra parenthesesjust add to confusion. (On the other hand, you _should_ use theparentheses in less obvious cases, even if you know that they're notneeded.)
3. Sort of. There are two wide spread conventions for formattingconditionals and loops:

   if ( cond ) {    code;}

   and:

   if ( cond ){    code;}

   In the first, I'd agree with him. The opening { is not that visible,so it's best to assume it's always there. In the second, however, I(and most of the people I've worked with) have no problem with omittingthe braces for a single statement. (Provided, of course, that theindentation is systematic and that you use this style consistently.(And a lot of very good programmers, writing very readable code, omitthe braces even when formatting the first way.)
4. NO. Things like if ( NULL == ptr ) are ugly enough to hinderreadability. Write the comparisons intuitively. (Which in many casesresults in the constant on the right.) His 4 is bad advice; anythingwhich makes the code unnatural makes it less readable.
5. NO. Anything but int is reserved for special cases. Toexperienced C and C++ programmers, the use of unsigned signals bitoperators. C++ doesn't have a real cardinal type (or any othereffective subrange type); unsigned doesn't work for numeric values,because of the promotion rules. Numerical values on which noarithmetic operations would make sense, like serial numbers, couldpresumably be unsigned. I'd argue against it, however, because itsends the wrong message: bitwise operations don't make sense either.The basic rule is that integral types are int, _unless_ there is asignificant reason for using another type.
6. NO. Doing this systematically is misleading, and doesn't actuallyprotect against anything. In strict OO code, delete this; is oftenthe most frequent case (and you can't set this to NULL), andotherwise, most delete are in destructors, so you can't access thepointer later anyway. And setting it to NULL doesn't do anythingabout any other pointers floating around. Setting the pointersystematically to NULL gives a false sense of security, and doesn'treally buy you anything.

Look at the code in any of the typical references. Stroustrup violatesevery rule you've given except for the first, for example.

I'd suggest that you find another lecturer. One who actually knows whathe's talking about.