Who's using MFC's VERIFY Macro?

To开发者_如何学Go think ... there I have been happily programming in an MFC riddled environment for years, using ASSERT() whenever it seemed OK and just today I (was) stumbled upon the VERIFY Macro: http://msdn.microsoft.com/en-us/library/fcatwy09%28v=VS.71%29.aspx

It's basically the same as ASSERT() except the expression will not be removed in release builds (the check will, but the expression will still be evaluated).

#ifdef _DEBUG
#define VERIFY(f)          ASSERT(f)
#else   // _DEBUG
#define VERIFY(f)          ((void)(f))

I can see a few uses for it, but I was wondering if others use it regularly in their code base and if anyone has seen any adverse side effects of using it.

cheers.

When I used to do MFC programming, I used it all the time.

Basically everything which returns something that I'm normally too lazy to check the return from, but which Lint then whines at you about, I would wrap in a VERIFY. (Calls like ::CloseHandle, for example)

There cannot be any adverse side effects to using it in a released product, because it's a no-op on a release build anyway.

In my first programming gig, 15 years ago, I managed to speed up an existing project quite a lot. They had tons of ASSERTs in their code, but relied on the side effects. That meant they could only build debug builds, and their program would stop working in release mode. I just replaced all the ASSERTs by VERIFYs.

Say you have code like this:

  ...
  const int optional_return_value = AnyOldFunctionOrMethod(params);
  ASSERT(optional_return_value == 42);
}

This will give warning C4189: 'optional_return_value' : local variable is initialized but not referenced in the release build.

The VERIFY Macro can avoid this, either by doing the function call + check on one line in the VERIFY macro (like Will suggested in his answer) or by just using VERIFY instead of ASSERT in the check line.