Debugging aid

[CFred]

It's been a while since I contributed to this forum so I thought I would share macros that I use to help with the development of programs. The attached zip file contains the include file, DebuggingAid.h, that contains a set of macros for debugging together with a demonstration program.

Features

1. The facility to output formatted strings to a console. The formatted string can contain variable values. I found a feature similar to this invaluable in PureBasic.

2. Displays programmer's messages during compiling in the window under the project tab. The message includes the file and line number of the source code. Double clicking on the message takes the programmer to the relevant part of the code, so this can be used as a placeholder/bookmark.

3. An Assertion macro that is similar to the assert macro in the C language - I included this macro so that all the debugging facilities are in one module. This macro shows the name of the module that has an error, the line number on which it occurred and the expression that triggered the error. Unlike the assert macro in  C, this does not show the function where the error occurred, but it has a neater display.
The program stops running after the Assertion macro responds to an error.

The features can be used with ANSII or Unicode.

Usage
Include the header file in the module to be debugged:

Code: [Select]

#include "DebuggingAid.h"
To ensure the features are available, ensure that the line

Code: [Select]

#define DebuggingOn
is not commented out in the include file.

If this line is commented out then the macros for displaying messages to the console and the Assertion macro will be replaced by a blank line in the compiled code. However, the macro to display messages while compiling programs will still be available.

To use Unicode, uncomment the lines

Code: [Select]

//#define UNICODE  //Windows
//#define _UNICODE  //C runtime


Displaying messages and variables in a console.
To open a console for receiving messages at run time, include the macro OpenConsole in a program module. I usually include this line in response to the WM_CREATE message that is sent to the main window.

To write to the console, use the macro ConsoleOutput. The first argument of this macro is a formatted string that uses the same convention as the function wsprintf() ie include place holders such as %s for a string and %i for an integer. Include the values of these placeholders after the formatted string, separated by commas.

Example:

Code: [Select]

ConsoleOutput("Variable value: %d\n", 5);
ConsoleOutput("This is %s number %i", TEXT("test"), 7);
Displaying messages when compiling a program
This uses the MSGCOMPILE macro that must be implemented using a #pragma directive.
The message should not be placed in quote marks.

Example:

Code: [Select]

#pragma MSGCOMPILE(Need to insert code for this function later)
Using the ASSERTION macro
Use the macro ASSERTION followed by an expression in brackets. If the expression is FALSE then a message box displays the module and line number of where the error occurred, together with the expression.


Conclusion
If anybody has any other debugging macros that help with programming then post them here and I will add them to the attached file.

[Vortex]

Hi CFred,

Thanks for the application. The application is crashing in the test case below. Operating system : Windows 7 Sp1 64-bit.

To reproduce the issue :

a) Click Action 1.
b) Click OK in the message box.

[John Z]

Hi CFred,

Confirming Vortex's finding, but on Win 11 Home 23H2, 64 bit.

Start demo click Action 1 -

Attached screen shot, after clicking OK a moment or two goes by
then it all terminates.

John Z

Hmmmm

The program stops running after the Assertion macro responds to an error.

Does this mean the demo is SUPPOSED to stop (looking like a crash but intentionally stopping?) if so a message box saying 'terminating due to Assertion error" would be helpful before aborting the program -  just a thought

[frankie]

Nice job CFred.
John, Erol,
The macros starts debugging from the point where they are inserted, what you see isn't a crash, but the execution that changes in debug mode, and if you haven't assigned a system debugger the program ends. Try to compile the executable with debug symbols and start in debug mode.
This feature could be very interesting to solve the limitation of PellesC debugger that makes impossible to set a break-point inside a switch-case. 

[CFred]

The file DebuggingAid.h uses the function DebugBreak() that initiates a breakpoint exception. If this is not handled, then the process terminates. You could change the line

Code: [Select]

DebugBreak();}
to

Code: [Select]

ExitProcess(1);}
to obtain a cleaner termination of the program when ASSERTION responds to an error.

The number in brackets is an error code - this can be changed if required.

[John Z]

Hi CFred,

It looks very handy and very well done.
It was just that the Demo program termination was unexpected.

John Z

[Vortex]

Hi CFred,

Thanks for the new release, tested successfully on Windows 10 64-bit.

Hi Frankie,

Thanks for the heads up.

[MrBcx]

Hi CFRED,

Code: [Select]

Unlike the assert macro in  C, this does not show the
function where the error occurred, but it has a neater display.
You probably know this but, if not, the C99 __func__ is useful for
returning a string containing the name of the function it is invoked within.

In the example below, sizeof(__func__) returns 7 which is the strlen of
"myfunc" + the terminating null.

Code: [Select]

#include <stdio.h>

void myfunc(void)    { 
   printf("%s\n", __func__); 
   printf("size of __func__ = %d\n", sizeof(__func__)); 
} 

int main() { 
   myfunc(); 
}

https://www.ibm.com/docs/en/i/7.5?topic=identifiers-func-predefined-identifier

[CFred]

Thanks, MrBcx

I can include __func__ for non-unicode programs as follows:

Code: [Select]

#else
#define ASSERTION(x) if (!(x)){ \
wsprintf(szDebugMessage, TEXT("Module: %s\n Function: %s\n Line: %d\n"), TEXT(__FILE__), TEXT(__func__), __LINE__); \
and this works. But when I try to include it for unicode programs using

Code: [Select]

#ifdef _UNICODE
#define ASSERTION(x) if (!(x)){ \
wsprintf(szDebugMessage, TEXT("Module: %s\n Function: %s\n Line: %d\n"), TEXT(__FILE__), TEXT(__func__), __LINE__); \
I get the error message:

Undeclared identifier 'L_func_' (did you mean: __func__?).

For this reason I did not include a reference to __func__ in the debugging file.

[TimoVJL]

wsprintf have this :

hs, hS
String. This value is always interpreted as type LPSTR, even when the calling application defines Unicode.

[frankie]

__func__ is a local symbol pointing to an ascii string in memory, not a predefined preprocessor symbol expanding to a string. So you cannot prepend the 'L' for wide char, it will result to a new, undefined, symbol L__func__.
Because the system function wsprintf() makes no difference between standard and wide strings it becomes very difficult to handle the macro in both versions: unicode and not unicode.
Timo suggestion can be a solution to try to solve, but I noted also some things that could be simplified (build the output string in a single passage), and some coding could be objectionable (i.e. copy a string on itself using unsafe functions as in _tcscpy(szDebugMessage, wcsrchr(szDebugMessage, TEXT('\\')) + 1);).
So having to solve the issue, I rewrote that part respecting CFred Idea for this helper.
I attach the modified project here. It has been tested for 32 and 64 bits, unicode and not.

EDIT: Sorry I posted the wrong file, now the whole project is posted. Thanks John.
EDIT: Fixed more.

[frankie]

Fixed some residual errors and simplified more.
Download from previous post.

[Vortex]

Hi Frankie,

Thanks, your version works fine under Pelles debugger. Operating system : Windows 7 64-bit

[John Z]

Thanks frankie!

Always something to learn from your code! 

Impressed,

John Z

[CFred]

@Frankie: Thanks for tidying up the debugging code. I was not aware of the function aswprintf() and asprintf(), this will be useful for other projects.