Okay, I know you think I’ve seriously hit the crack pipe here. Curly Braces, as I’m sure we all know, are fundamental to programming in most languages. This is true no more so then here in C#. We use them for if, for, using, do, while, namespace scope, class scope, method scope and getters and setters for parameters.

So how could I dare to say the {} is an often unused operator? Well, I’m specifically talking about a use of the operators in this case, not the operators themselves.

Did you know you can use curly braces by themselves? Take a look at this:

public Window1()
{
    InitializeComponent();

    {
        int [] intList = { 1, 2, 3, 4, 5, 6 };
        var evens = intList.Where(x => x % 2 == 0);
    }

    {
        int[] intList = { 1, 2, 3, 4, 5, 6 };
        var odds = intList.Where(x => x % 2 == 1);
    }
}

Yes! That there are curly braces by themselves!

Why the hell would anyone want to do this? I find myself using them all the time when writing up samples where at http://www.formatexception.com. The reason is that I test all the sample code I post up here that I write. This has been a big help especially since it seems like a lot of the linq code here derives from msdn samples and, believe it or not, not all of them work.

What this means is that if I want to do a write-up on linq where I’m using the where method on IEnumerables (like above) I write the code surrounded by curly braces. Because each is it’s own scope, call it internal method scope if you will, there won’t be any name collisions. It’s like doing an if(true){} without the if(true), or like using the using keyword as in:

using(Stream ImageStream = new MemoryStream(File.ReadAllBytes(ImagePath)))
{
    BitmapImage bi = new BitmapImage();
    bi.BeginInit();
    bi.StreamSource = ImageStream;
    bi.EndInit();
    
    Image imageFromFile = new Image() { Source = bi };
    //dump image into wrap panel in form
    imagePanel.Children.Add(imageFromFile);
}

except you don’t have to have a class the implements IDisposable.

So, where would you use this? If you’re real paticular (i.e. anal) about the your variable names. For instace the following code is not valid:

{
    int [] intList = { 1, 2, 3, 4, 5, 6 };
    var evens = intList.Where(x => x % 2 == 0);
}


int[] intList = { 7, 8, 9, 10, 11, 12 };
var odds = intList.Where(x => x % 2 == 1);

The reason is that the set of curly braces define a child scope but the second intlist exists in the parent scope. Sibling scopes can have variables of the same name but not parent/child scopes. If I really wanted my intList to be named “intList” and assuming it would only be needed within the child scope I could put a second set of curly braces around the other code and be free to name my intList to, um, “intList”.

I have never really found a use for this in production code to be honest. I use it a lot when writing up samples for my posts, but not in production code. I suppose if I was adamant about my variable names I would use it more and I think a few of you out there are. I, however, have no problem simply naming my second int list to intListForOdds.

So that is the curly braces and their often unused purpose.

Later,
Brian

From MSDN:
The checked keyword is used to explicitly enable overflow-checking for integral-type arithmetic operations and conversions.
By default, an expression that contains only constant values causes a compiler error if the expression produces a value that is outside the range of the destination type. If the expression contains one or more non-constant values, the compiler does not detect the overflow.

The unchecked keyword is used to suppress overflow-checking for integral-type arithmetic operations and conversions.
In an unchecked context, if an expression produces a value that is outside the range of the destination type, the overflow is not flagged.

Okay, so what the hell does this mean?
The C# compiler checks at compile time for overflow exceptions.
If you do:

int tooBig = 2147483647 + 10;

you get the error “The operation overflows at compile time in checked mode.” The problem arises when you use variables. Since a variable could be anything the compiler doesn’t check for overflows. If you do:

int ten = 10;
int tooBig = 2147483647 + ten;

your code will compile but the value of tooBig will be -2147483639. This is because default behavior of the runtime environment is to skip checking for overflows and your values just wrap.

So, what do you care?

Most likely you don’t. I’ll be honest. Chances are you’re not writing algoritms so important that if you overflow the world is going to come crashing down about you. Every once in awhile you do, however, come across some peace of critical software that may need to handle overflow exceptions. That is where the checked and unchecked operations come into play.

The problem is that checking every math operation for an overflow is slow. Okay, maybe slow is a bit much. It is, however, a couple of microseconds that you could be using on other things and it’s really slow if an overflow exception is thrown and you have to handle it. In math heavy operations and algorithms these few microseconds could add up to a lot of time so be sure that your code is critical enough that an overflow must be handled.

So, how do we fix this? We use the checked operation (in either the block or expression form).

//block
checked{
    int twenty = 10 + 10;
}
//expression
int thirty = checked(10 + 20);

This tells the compiler to check the numbers and if there is an overflow throw an overflow exception.

The opposite of the checked operator is unchecked:

//block
unchecked{
    int twenty = 10 + 10;
}
//expression
int thirty = unchecked(10 + 20);

This works just like the default behavior of not checking for overflows with variables. Since this is done automatically you probably won’t use this too often unless you start using the checked operator. The nice thing is that you can combine both checked and unchecked for the appropriate values.

unchecked
{
    int ten = 10;
    int tooBig = checked(2147483647 + ten);
    Console.WriteLine(i3);
}

yields an overflow exception being thrown since 2147483647 + ten overflows. Conversely,

checked
{
    int ten = 10;
    int tooBig = unchecked(2147483647 + ten);
    Console.WriteLine(i3);
}

results in a value of -2147483639 since the unchecked means the runtime environment to not check for overflow.

That’s all for now,
Brian