A tricky loop I’d like to show you.

First of all a quick explanation of the two functions I use.

• log2 computes the base-2 logarithm of x.
• ceil rounds, it returns the smallest integral value that is not less than x.

/* compute the ceil(log2(x)); i,x are unsigned; x is not 0 */
for( i = x>>1, n = 0; i != 0; i >>= 1, n++ ) {
}

In C we can have loops that have nothing in their body. You should use braces around an empty body. This allows you to expand the body if necessary. Further it gives us a visual clue that something out-of-the-normal is going on.

VERIFY can be used for things that should never fail, though you may want to make sure you can provide better error recovery if the error can actually cause a crash in a production system.

The C language provides a macro, called assert, that is used to verify conditions that must be true at any point of the program. These include preconditions, postconditions and invariants, all of which are explained in introductory programming courses. Whenever an assertion is violated, the program is abruptly stopped because there is most likely a bug in its code.

Many programmers put ASSERT macros liberally throughout their code. This is usually a good idea. The nice thing about the ASSERT macro is that using it costs you nothing in the release version because the macro has an empty body. Simplistically, you can imagine the definition of the ASSERT macro as being

#ifdef _DEBUG
#define ASSERT(x) if( (x) == 0) report_assert_failure()
#else
#define ASSERT(x)
#endif

(The actual definition is more complex, but the details don’t matter here). This works fine when you are doing something like

ASSERT(whatever != NULL);

which is pretty simple, and omitting the computation of the test from the release version doesn’t hurt. But some people will write things like

ASSERT( (whatever = somefunction() ) != NULL);

which is going to fail utterly in the release version because the assignment is never done, because there is no code generated (we will defer the discussion of embedded assignments being fundamentally evil to some other essay yet to be written.

That’s what VERIFY is for. Imagine the definitions of VERIFY as being

#ifdef _DEBUG
#define VERIFY(x) if( (x) == 0) report_assert_failure()
#else
#define VERIFY(x) (x)
#endif

Note this is a very different definition. What is dropped out in the release version is the if-test, but the code is still executed.

You always have to keep in mind that in the release version of MFC, VERIFY evaluates the expression but does not print or interrupt the program. For example, if the expression is a function call, the call will be made.

At least this is an example how VERIFY can be used (codelines out of the tar-1.16 project)

/* Verify requirement R at compile-time, as an integer constant expression.
   return 1.  */
 
# ifdef __cplusplus
template <int w>
  struct verify_type__ { unsigned int verify_error_if_negative_size__: w; };
#  define verify_true(R) \
     (!!sizeof (verify_type__<(R) ? 1 : -1>))
# else
#  define verify_true(R) \
     (!!sizeof \
      (struct { unsigned int verify_error_if_negative_size__: (R) ? 1 : -1; }))
# endif
 
/* Verify requirement R at compile-time, as a declaration without a
   trailing ';'.  */
 
# define verify(R) extern int (* verify_function__ (void)) [verify_true (R)]
 
#endif

Everyone knows that floating point numbers do have finite ranges, but this limitation can show up in unexpected ways. For instance you may find the output of the following lines of code surprising.

float f = 16777216; 
cout << f << " " << f+1 << endl;

Against expectations this code prints the value 16777216 twice.

What happened? According to the IEEE specification for floating point arithmetic, a float type is 32 bits wide. Twenty four of these bits are devoted to the significand (what used to be called the mantissa or also coefficient) and the rest to the exponent. The number 16777216 is 224 and so the float variable f has no precision left to represent f+1.
A similar phenomena would happen for 253 if f were of type double because a 64-bit double devotes 53 bits to the significand.

The following code prints 0 rather than 1.

x = 9007199254740992; // 2^53 
cout << ((x+1) - x) << endl;

We can also run out of precision when adding small numbers to moderate-sized numbers. For example, the following code prints “Sorry!” because DBL_EPSILON (defined in float.h) is the smallest positive number ε such that 1 + ε ≠ 1 when using double types.

x = 1.0;
y = x + 0.5 * DBL_EPSILON;
if (x == y)
    cout << "Sorry!" << endl;

Similarly, the constant FLT_EPSILON is the smallest positive number ε such that 1 + ε ≠ 1 when using float types.

I think it’s time to disclose the secret of that piece of code. First of all it’s not that tricky as you might have expected. You just have to get some basic knowledge about memory allocation.

Probably most programmers if they have a look at those few lines would say that here a beginner didn’t pay attention and that the program will poorly fail by an access violation error or something similar.

For everybody who didn’t try out this snippet himself:
If y is declared before x in the line the loop is becoming an endless loop. If it’s declared the other way round the program seems to work correctly.

First of all I have to clarify that even if we declare y before x in that line, x is first allocated in memory. It’s read by the machine from right to left.
Second thing which is important to know is that memory is always allocated from top to bottom (for our imagination).

For better explanation I changed the order of x and y:

int y,x;
int feld[5];

On the stack first of all y gets it’s space of 4 bytes after that x gets the same. After that above those two the array gets 5 times 4 bytes (20 bytes).

After running the loop 5 times (from 0 up to 4) the array is filled with values. Until here everything works as it should.

But wrongly the loop is run one more time (<=5) and that's why the next value is written into the space that was allocated for x (as you can see on the picture below). In fact x gets overwritten...

The endless loop was caused by writing every time again 1 into y.
This is no black magic and it’s also not illegal according to the C++ standart. It’s just a bad error done by the programmer which often happens and usually almost not fineable in a few minutes.

It should just show you to be careful with your allocations.

Please have a look at this code snippet and try to tell me what you’re expecting it to print out.

#include <iostream>
using namespace std;
 
int main()
{
	int x,y;
	int feld[5];
 
	x=6;
	for(y=0;y<=5;y++)
	{
		feld[y] = 1;
		cout << y << endl;
	}
	cout << x << endl;
 
return 0;	
}

Mention that the array size is 5 and the for loop goes till 5 (including!).

If you don’t get the solution why this happens the way it happens it might help you to know changing the order of decleration of x and y does cause a totally different output.
I will give you the solution to that miracle in a few days…

Have fun

NULL in c is defined as (void*)0, While for C++ its simple 0. Any ideas ?

#ifdef __cplusplus
#define NULL 0
#else
#define NULL ((void *)0)
#endif

As you know C++ is a direct descendant of C that retains almost all of C as a subset. Maybe it’s because of the fact that C++ provides stronger type checking than C and directly supports a wider range of programming styles than C.

Obviously it’s not that important because well written C tends to be legal C++ also.