CMake, Checkpoints and stdout report

Jul 3, 2013 at 11:18 AM

First of all, thanks for this great tool. It is vastly superior to the crtdbg.h based automated leak checking I used to add to all my projects, the stack trace in the debug output window is a lifesaver.
While adding it to my projects I noted three comparatively minor things I would need and I have created a fork here, where I gave them a first shot:
I am using GIT for the first time so please forgive me if I have done anything wrong.

The changes/additions are:
VLD clears or sets the flags to report to debugger and/or stdout only if the report to file option is also set and a report file name is supplied. This could be fixed with just a minor change.
I (still) use VS2008 a lot and I rely heavily on CMake for all my projects. So to build vld, where applicable include it in my solutions created a CMake file for the dll. I used the flags that 123user123 extracted and posted here
and otherwise used my standard CMake file for DLLs and added an INSTALL target that pretty much re-creates how vld is distributed in binary form. Please let me know whether this is useful - if so I might end up creating the necessary CMake files for the test targets, too. I have started and included mfc_detect but as I don't need it myself right now put it on hold for the rest of the test targets.
In test suites and during debugging I frequently use leak detection while running the program, e.g. checking for any memory leaks while running a sub-test. Of course this could be done by marking all leaks as reported before the run with the existing API. However then, you get no information about whether these allocations will be freed later on (in another thread, at program exit because they are connected to some static variable etc.). Also sometimes it is interesting to only look at leaks in the current thread.
I therefore added a few new functions:

Basically count up a thread-specific checkpoint counter and a global checkpoint counter.

Do the same as the non-Ex functions but you can restrict the action to leaks allocated in a specific thread (or not, if threadId is -1) and give a range of checkpoints between which the leaks must have been allocated (if threadId is -1 the global checkpoints are considered, if threadId is an actual id, the thread specific checkpoints are used).
This is not the cleanest of all solutions but it works for me - maybe it is of interest to others.

Best regards,