5. Configuration

In HeapCheck.c, you can change the way the library behaves by changing:

1. MAX_ALLOCATIONS:
   Total concurrent allocations possible. If your program needs more, you'll get an assertion at runtime telling you to increase this.
2. MAX_ALLOCATABLE_BLOCK:
   Total heap available to the application. If your program needs more, you'll get an assertion at runtime telling you to increase this.
3. NO_VC_HEAP_ERRS:
   It is possible to write code that bypasses the mechanisms of the library, and allocates from the standard VC-heap. An example is code inside the runtime library which is pre-compiled and uses different allocation mechanisms. Example: an enhanced new() operator in iostrini.cpp (line 21) and cerrinit.cpp (line 21) where _new_crt() is used. _new_crt() maps through a #define to a new() operator that takes extra parameters. HeapCheck can't catch this call, so when the time comes for the deletion of these blocks, the library's delete operator doesn't find them in it's tables. It is capable to understand that these are VC-heap blocks though, through the use of _CrtIsValidHeapPointer. If you #define NO_VC_HEAP_ERRS, the library won't complain for such situations. This is the default, but if your code issues direct calls to _malloc_dbg(), _calloc_dbg(), etc, you should disable this. If the previous text sounds like Chinese, leave it as it is.