Wednesday, February 25, 2004

Re: Return of the Assertions

assert can be enabled/disabled during running code however, with the -ea , -da options.

how is it in .net ?

The .NET languages don't have an assert keyword. The framework has a class called Debug in the System.Diagnostics namespace which has an Assert() method.

The CLR depends on the presence of a "DEBUG" symbol to JIT compile Assert calls. You use the #define statement to define the symbol -> "#define DEBUG". The methods in class Debug have an attribute called Conditional associated with them. Ex...

public class Debug
public static void Assert( bool condition );

At compile time (i.e. JIT compiling to native code from IL code), when it comes across the Assert() methods, it sees that it has the Conditional attribute associated with it. It checks to see if the DEBUG symbol is defined. If yeah, it goes ahead and compiles, else skips it. So, no increase in code size and doesn't hurt performance.

Actually .NET has another class called Trace. That class also has Assert() methods, which essentially do the same thing as Debug Asserts. The difference is that Trace uses a different symbol. It uses "#define TRACE". Also, the Conditional attribute on those methods are passed "TRACE".

They have two cause you want some assertions only during debug time, (Debug.Assert()) and others ALL the time, even on release builds (Trace.Assert()).

another question (probably the dumbest however) i had is whether FooBar is supposed ot mean anything. as i i have seen so many FooBar examples, i wonder if it was some historic programming whatever. u guys know what its supposed to signify or do i just need a break !!

I don't really think it means anything specific. It's just something that's been passed from gen to gen in program examples and it's stuck. Here's a def from the "The Jargon Dictionary"

There is another acronym that sounds the same - FUBAR (Fucked Up Beyond All Recognition)

No comments: