Need a preprocessor identifier when $DEBUG is used

[a740g]

Not sure if we already have this. But I checked the wiki and found nothing.

Having an identifier (like DEBUG for example) auto-set when the $DEBUG metacommand is used can be useful to include code that we only need when debugging.

For example:

$DEBUG

$If DEBUG Then Print "We are debugging" $End If

[SteveMcNeill]

Is this really a necessary change to make? The vast majority of the user's code would have to be inside $IF blocks, as above, and all they'd need to do is add a single truth statement to the start of the program to toggle when they wanted to see the debug information or not. IE:

$LET DEBUG = FALSE

'do all sorts of stuff

$IF DEBUG THEN Print "We are debugging" $End If

Change that $LET from FALSE to TRUE, and the user can manually turn on that debug segment, without necessarily having to rely on the built in vWatch debugging system.

QB64 source is quite complex and longish already. I'm not certain we'd see much actual benefit to digging into and sorting an extension out for this, when it's already so easily available for an end user. ;)

[a740g]

Yes true. But QB64 IDE automatically wants to add $DEBUG at the top when the line column is clicked. It would be nice if we could detect this using the preprocessor rather than manually editing.

[mkilgore]

Personally I'm somewhere in-between - the suggestion seems reasonable to me, but Steve's not wrong that you can get basically the same functionality by just defining DEBUG yourself. That said I don't actually know all that much about how $DEBUG works, I think I should look into it a bit more.

Seeing your snippet of code, what would also be nice is if you could wrap the whole thing into some kind of DebugPrint statement, rather than have the $ifs everywhere. You could almost get there with just a SUB, but it's not quite the same :-/ Any kind of change like that would require a fair amount more thought though :D

I would personally encourage you to give this change a shot if you feel like it. Looking at the qb64.bas code I don't think this is a hugely significant change to make, but even if we did decide to do it it's probably not something we would get to soon. I would not be opposed to adding this if we had a working version and it wasn't too complicated to add. The only thing I would suggest is make the define _DEBUG or something so it's less likely to clash with what people might already have.

[ghost]

I'm with Matt on this. I'm somewhere in-between. It sounds nice but can easily be replicated with your own $LET.

[mechatronic3000]

The though I had for this was to use it to turn off the checking when I'm debugging. Maybe also print a warning to turn off optimizations as well.

$DEBUG

' fast LOOP
DO
 $IF DEBUG = FALSE THEN
  $CHECKING:OFF
 $END IF

 'Do stuff really fast

 $IF DEBUG = FALSE THEN
  $CHECKING:ON
 $END IF
LOOP 

[FellippeHeitor]

If $debug is active and you're actually using its set of features you'll likely not need to print anything to debug the code really.

[RhoSigma-QB64]

To be honest, I think all this switching sould be done internally. If $DEBUG is active, then we could just silently disable $CHECKING:OFF and compile without the C++ optimizaton flags, even if those are set. The $DEBUG should simply have the highest priority over the other things. The user obviously wants to debug his code, so we should internally make sure it works as expected, rather than forcing him to meet this and that pre-conditions. The only thing is maybe a warning we should issue telling him that some of his used options/commands/features are currently disabled due to the use of $DEBUG and that it will be automatically re-enabled as soon as he's done debugging and removes the $DEBUG command.

[mechatronic3000]

Regardless if its internal or external a $DEBUG preprocessor variable would be nice.

For example on my larger projects I have found writing a log file to be helpful, because it can give me a history of a variable. So, if $DEBUG is active, It could switch on extra information to put into the log.

Ultimately, the end user can use that information how they choose, and there is no downside to having it.

[FellippeHeitor]

To be honest, I think all this switching sould be done internally. If $DEBUG is active, then we could just silently disable $CHECKING:OFF and compile without the C++ optimizaton flags, even if those are set

Yeah, about that...

$Checking:Off will remove all intervention in user's code, including the ability to debug those lines.

[flukiluke]

I think there is utility in having an identifier pre-defined whenever debug mode is active, as some commands are not conducive to debugging e.g.

$if not _DEBUG then
_fullscreen
$end if

With regards to $CHECKING, I hesitate to silently disable it when debugging as there are some programs that do otherwise okay tricks with _MEM but need $CHECKING:OFF to prevent the runtime checks getting in the way. The current warning seems sufficient.

[SteveMcNeill]

Isn't the simple solution just to set a variable yourself with $LET?

$DEBUG
$LET DEBUG = WHATEVER

$IF DEBUG = UNDEFINED THEN
    _FullScreen
$END IF

It's really only one extra line of typing for the user, and they can use it to toggle for when they want to test certain segments or others, as needed.

$DEBUG
$LET DEBUG = SCREEN0

$IF DEBUG = CONSOLE THEN
    $CONSOLE:ONLY
$ELSEIF DEBUG = SCREEN0 THEN
    SCREEN (120, 40, 0)
$ELSEIF DEBUG = SCREEN256 THEN
   SCREEN (640,480,256)
$ELSE 
   SCREEN (640, 480, 32)
$END IF