#if DEBUG

Archive
1

i saw today in the exmaples that they used this in the code .


 #if DEBUG
    Debug.Print(e.Message);
 #endif

So that made me think, if one does not use the #if and i switch to release mode, when then happens to the Debug.Print(e.Message); ?

In other words, after i disconnect the usb debug cable and turn the board on, is it still chewing up some cycles trying to do it, or is it smart enough to realize that its not connected and does not bother with it.

2

In release build all #DEBUG sections will be omitted. In debug build the calls will execute.

3

but that is if the “#if DEBUG” is in there, what if i remove the “#if DEBUG” and just leave the Debug.Print.

4

Then the Debug.Print will be called.

5

Unfortunately, this is true and is what I would consider a bug in NETMF. In the full .NET, the Debug class is skipped during a release build and it is therefore unnecessary to put in a #if block.

6

well thats good to know, and thanks for the heads up.

I wonder why there are so many examples that do not use the #if DEBUG.

7

I guess because that what it is in most cases - an example. It is up to you to make your final production code optimized for performance and such.

8

ya, but how is anyone supposed to learn if the examples are not teaching good practices.

9

I think this is especially confusing (or maybe misleading is a better word) for people coming from C/C++, where they’re used to things getting #ifdef’ed out when DEBUG isn’t defined…

If I had a vote, I’d vote that the Debug class got compiled into stubs or, better, nothing at all when built in release mode. That maybe or have a new class that gets compiled away into nothing in release builds and calls the existing Debug stuff in debug builds…

10

It should be consistent with the full .NET and not get compiled at all unless the DEBUG symbol is defined.

I’ve requested this of the NETMF team. Please vote for it.
[url]http://netmf.codeplex.com/workitem/1258[/url]

11

I often #ifdef out debug.print statements even when doing debug builds (I don’t like to depend on just the distinction between a debug adn release build.) You don’t always want them to be working as it can really slow things down and it can be helpful to be able to selectively turn groups of them on/off independently. You might also find that it might be helpful to have a few left on in a release build so you can connect with MFdeploy and monitor a device during long term testing.

For production code I would add a few lines to squirt out a warning if you leave any of the debug.prints on when doing a release build.

12

[quote]For production code I would add a few lines to squirt out a warning if you leave any of the debug.prints on when doing a release build.
[/quote]

Interesting idea… How do you detect this? Is there a OnDebugPrint event or something that could be handled to blink an LED or something?

13

I think he is talking about compile time warning.

14

Is this subject documented somewhere? I wonder how many people here know about this.

15

Do you mean C# preprocessor directives?

[url]Microsoft Learn: Build skills that open doors in your career

P.S. Forum bug. Looks like the script doesn’t respect url tags and cuts off .aspx in the above link.

16

There is no such compile time warning that I’m aware. I gathered that Jeff is already providing such a warning. Is this something you’re already doing or a warning you wish for?

17

@ Architect, no, is there documentation that basically says when going from .net to .netmf we no longer automatically remove the Debug.Print.

To bad the forum does not have a poll feature, i would bet that many do not know about this.

18

No there is not, but you can create your own with #warning directive.

19

I don’t see how that would help notify you that you forgot to #if a debug function. If you you remembered to #warning then you would certainly remember to #if. Is there a global application of #warning I’m not understanding? Sorry, it’s still early…

20

Or you can make sure that Debug.Print is not called in release by doing something like this:


        static void DebugPrint(string text)
        {
            #if DEBUG
                        Debug.Print(text);
            #endif
        }

or if you still want to use it in release, but prefer to be warned about it


        static void DebugPrint(string text)
        {
            #if !DEBUG
                #warning  Debug.Print is used in release build
            #endif

            Debug.Print(text);
        }

You have to use DebugPrint wrapper after that.