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

Mail Goggles, available at Google Labs, tries to prevent drunk e-mailing.

Google Mail has invented a way of stopping you sending emails that may later prove embarrassing.

Intended to help you overcome the urge to say what you really think late on a Friday night when you are a little the worse for wear, Google’s Mail Goggles asks you to solve “a few simple math problems after you click send to verify you’re in the right state of mind”.

Of course, you have to enable the feature first – Google isn’t trying to force you to take an unwelcome arithmetic test every time you want to send a message – and even if you do enable it, it doesn’t assume you’re drunk all the time.

“By default, Mail Goggles is only active late night on the weekend as that is the time you’re most likely to need it. Once enabled, you can adjust when it’s active in the General settings,” said Jon Perlow, a Gmail engineer.

Note: You can activate the feature in your Gmail or Google Mail account by clicking on the Settings tab on the top right of the screen and selecting Labs. Scroll down and you should find a brief explanation of the Mail Goggles feature and the option to enable it.

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.