You probably know about methods like Debug.WriteLine and Debug.Assert. A big part of their use is that they only do stuff if you are running a application compiled in Debug mode. If you are running in release mode, however, its like those calls in your code don't even exist - this way you can feel free to put helpful debug messages and checks in your code without worrying about the release version of the application being affected. Have you ever wondered how this is done?
Well, what happens in the end is that those calls really don't exist in a release compiled version of an application - they are literally ripped out of the code. But there is no magic going on here, and nothing that is specially restricted to Microsoft's own code - its actually just a plain old method attribute, one that we can use in our own code if we wanted to.
Heres the method signature for Debug.WriteLine:
public static void WriteLine(string message)
That ConditionalAttribute tag on the method signature means that the method call only really exists if the code is compiled in Debug mode (i.e., the symbol DEBUG is defined). For instance, take a look at the following (very simple) chunk of code:
{
class Program
{
static void Main(string[] args)
{
Debug.WriteLine("I'm a message!");
}
}
}
When this code is compiled in debug mode, if you take a look at the MSIL (Microsoft Intermediate Language, the language C# is compiled into) inside the executable, you will see the following:
extends [mscorlib]System.Object
{
.method public hidebysig specialname rtspecialname
instance void .ctor() cil managed
{
.maxstack 8
L_0000: ldarg.0
L_0001: call instance void [mscorlib]System.Object::.ctor()
L_0006: ret
}
.method private hidebysig static void Main(string[] args) cil managed
{
.entrypoint
.maxstack 8
L_0000: nop
L_0001: ldstr "I\'m a message!"
L_0006: call void [System]System.Diagnostics.Debug::WriteLine(string)
L_000b: nop
L_000c: ret
}
}
Now in all that mess of MSIL, you can probably see the call to Debug.WriteLine that prints out that string. But if you compile the exact same code in release mode, and look at the MSIL, you see the following:
extends [mscorlib]System.Object
{
.method public hidebysig specialname rtspecialname
instance void .ctor() cil managed
{
.maxstack 8
L_0000: ldarg.0
L_0001: call instance void [mscorlib]System.Object::.ctor()
L_0006: ret
}
.method private hidebysig static void Main(string[] args) cil managed
{
.entrypoint
.maxstack 8
L_0000: ret
}
}
Now there is no trace of the Debug.WriteLine call at all - even the string we were going to print out, it is completely gone.
So how do we use this attribute? Well it's as simple as what was done for Debug.WriteLine - just drop the attribute on top of the method that you want to conditionally compile out. It doesn't have to be the DEBUG symbol, either - it can be for symbols you have defined yourself. For instance, say you wanted to gather some performance data when the symbol TIMERS is defined. You could have some code like the following:
{
private static Dictionary<string, Stopwatch> _Stopwatches
= new Dictionary<string, Stopwatch>();
[ConditionalAttribute("TIMERS")]
public static void StartStopwatch(string key)
{
if(_Stopwatches.ContainsKey(key))
{ return; } //Stopwatch already running
_Stopwatches.Add(key, Stopwatch.StartNew());
}
[ConditionalAttribute("TIMERS")]
public static void StopStopwatch(string key)
{
if(!_Stopwatches.ContainsKey(key))
{ return; } //No such stopwatch currently
var watch = _Stopwatches[key];
watch.Stop();
_Stopwatches.Remove(key);
Console.WriteLine(String.Format("Timer: {0}, {1}ms", key,
watch.Elapsed.TotalMilliseconds));
}
}
The use of the conditional attribute there means that those two calls - StartStopwatch and StopStopwatch - only exist when the TIMERS symbol is defined. So if you take the following code and compile and run it:
class Program
{
static void Main(string[] args)
{
TimerCalls.StartStopwatch("SumNumbers");
int total = 0;
for (int i = 0; i < 10000; i++)
{ total += i; }
Console.WriteLine(total);
TimerCalls.StopStopwatch("SumNumbers");
Console.Read();
}
}
You get this output:
Timer: SumNumbers, 2.7013ms
But if you take out that #define TIMERS statement at the top, you get this output:
Now I know this could technically all be done with#If statements, as we covered in The C# Preprocessor - An Overview, but using #If statements everywhere starts to really clutter code. In my opinion it makes code harder to read - plus you end up having to if-def out every single instance of whatever you are conditionally compiling. Using the ConditionalAttribute guarantees that every call is automatically stripped out - no worries that you missed one, or someone else added one in and forgot to add the if-def.
Well, that's it for ConditionalAttribute, another one of those obscure but handy features of C# (and the other .NET languages). The Visual Studio solution with the TimerCalls class is below, if you want to grab it and play around. As always, if you have any questions, drop a comment below and I will try to answer it.
03/10/2009 - 12:38
I really like that, thanks! Excellent for code that demands quick performance, this way you can monitor the time each function takes to execute without having preprocessor directives all over the place :).
04/05/2009 - 12:24
How come my compiler defines the debug flag even in Release mode where I have chosen not to do this?
When compiling from Visual Studio 2008, the compiler is still defining "/debug-", which seems to result in methods with the conditional attribute still being included.
Looking at the documentation the "/debug-" equals no debugging info at all, but seems enough to still render conditional attribute useless.
Any ideas?
//Portablenut