September 2010 - Posts

My Silverlight book is out!
Wed, Sep 29 2010 8:51

In this last year, I’ve been working with Silverlight in several projects at work. At the same time, I’ve been writing about it and I’m proud to announce that my Silverlight book is out. Once again, if you’re living in Brazil, you should be able to get it from the local bookstores or from the distributor (Zamboni – more detais on the contact here).

Now, I guess it’s time to go back to the HTML world…

by luisabreu | 3 comment(s)

Filed under: Books

Back to methods: overloading
Wed, Sep 22 2010 20:54

After a small JavaScript detour, I’m back into .NET land. We’ve already seen several interesting details regarding methods, but we still haven’t really discussed the concept of overloading. So, what’s method overloading? The concept is simple, but before, we should probably find a good enough definition for a method. For now, lets define a method as a name that represents a piece of code which performs some operation on a type or on an instance of a type.

If you’ve been doing C# for some type, then you know that you can have several methods with the same name, provided they have a different set of arguments. Ok, here’s a small sample which shows the concept:

public class Student {
    //static overloads
    public static void SayHi(Student std) {
    }
    public static void SayHi(Student std, String msg){
    }
    //instance overloads
    public void SayHi() {
    }
    public void SayHi(String msg) {
    }
}

The previous snippet shows how you can overload static and instance methods. In C#, you can only overload based on a different set of parameters. That means you cannot add the following method to the Student type without getting a compilation error:

//can't overload based on return type
public String SayHi(String msg) {
}

Now, do keep in mind that the CLR does allow this kind of stuff, ie, it does allow you to overload with a different return type. Anyway, we’re writing C# code, so to achieve that, we really need to write IL (which is not going to happen right now, so we’ll consider this paragraph a small side note:)).

Ok, back to C#…so why doesn’t C# allow overloads based in the return type? That happens because overloading is based on having different method signatures. In C#, a method signature consists of its name, the number of type parameters and the type and kind of each of its parameters (considered from left to right). Besides the return type, in C# the params keyword and the type parameter constraint (when you’re using generics) aren’t part of the method signature. Another interesting gotcha is that you cannot override solely based in the out/ref modifiers (as we’ve seen that in the past). Interestingly, the our/ref keywords are considered part of the signature for hiding/overriding purposes.

Overload resolution is an important concept which is used to decide which method will be called when you' write code like the following:

var std = new Student();
std.SayHi("Hello");

The algorithm for finding a method involves several steps. Instead of describing the complete process here (which would involve some serious copying of the C# spec) and since  this is becoming a large post, I guess I’ll just redirect you to the C# spec for getting the complete story on method overload resolution. So, open your C# spec and read the 7.5.5.1 section carefully to see what I mean…And that’s it for now. Tomorrow, we’ll continue our basic tour around .NET and the CLR. Stay tuned for more.

by luisabreu | with no comments

Filed under: C#, Basics

Oh damn! Can’t you see that’s a constructor?
Wed, Sep 22 2010 19:05

Even though I’ve been in Silverlight/C#/WCF land in these last months, the truth is that I’ve always been a JavaScript aficionado. In fact, if you’ve been reading my blog, you’ll probably recall a small series I’ve done on it a few months ago(if not, then don’t worry: you can still read it here). After speaking with a friend today, I think I might have missed a cool advice on how to define constructors in JavaScript.

As we all know, JavaScript OO programming is a little different from what we’re used to in traditional languages like C# or Java. You see, you can’t really reuse the same style of programming because things work in a completely different way in JavaScript land. Anyway, I still believe that it’s one of the coolest, more flexible languages you can use  (provided you don’t try to write JavaScript a la C# or Java). I’m not really getting into details here, but there are times where you want to create a constructor. oh, and yes, in JavaScript a function can be a constructor. And this is where problems might occur. Let’s start with a simple example:

var Point = function (x, y) {
    this.x = x;
    this.y = y;
}

var pt = new Point(1, 1); //correct usage
var anotherPt = Point(1, 1);//hum...not the intended usage

Ok, so can you see what’s happening here? Btw, before you start laughing, I’ve seen this happen  in the past (yes, in the real world!). When Point was created, it was meant to be used as constructor. But that doesn’t mean that a rookie or someone who is not paying attention can’t  call the Point function directly without using the new instruction. When that happens, the this special variable won’t point to a Point instance. In this case, it was probably referencing the window object, but it all depends on the existing context at time of invocation.

Now, if you’re writing frameworks, this is really a nightmare. You need to have some way of not allowing this. The good news is that there’s a way to fix this and it involves using the instanceof operator in 2 or 3 lines of code. Take a look at the next snippet:

var Point = function (x, y) {
    if (!(this instanceof Point)) {
        return new Point(x, y);
    }
    this.x = x;
    this.y = y;
}

And that’s it! really! When the function is invoked, we start by checking if this points to an instance of Point. When you use new, this does reference a Point instance. However, that doesn’t happen when you call the Point function as a function. With this small change, you’re ensuring that you’ll always get a new initialized Point instance from that method. Wasn’t that easy enough? And that’s it for now. Stay tuned for more.

by luisabreu | 2 comment(s)

Filed under: Javascript

Operator overloading
Mon, Sep 20 2010 13:41

In some languages (ex.: C#), you can customize the way an operator works. For instance, if you take a look at the String type, you’ll notice that it has these peculiar looking methods:

public static bool operator !=(string a, string b);
public static bool operator ==(string a, string b);

What you’re seeing here is known as operator overloading. Since the String class introduced these methods, you can write the following code to compare strings (btw, when comparing strings, you probably should be more explicit so that someone  that reads your code in the future knows exactly which type of comparison you’re performing):

String str1 = "hi";
String str2 = "hi";
Console.WriteLine( str2 == str1);

Operator overloading isn’t a CLR feature, but a compiler feature. In other words, the compiler is responsible for mapping the operators used in the source code into a method call which can be understood by the CLR. Now, in theory, you’re probably thinking that you can call the static method shown before directly:

Console.WriteLine(String.operator==(str1, str2));

But no, the truth is that you can’t do that (if you try, you’ll get a compiler error which says something like “invalid term: operator”). Even though the CLR doesn’t understand operators, it does specify how languages should expose operator overloads. If a language decides to support operator overload, then it must follow the CLR defined syntax and it must generate methods which match the expected signature. In the case of the == operator, the compiler is supposed to generate an op_Equality method. In case you’re thinking of trying to call that method directly from C#, don’t: you’ll end up getting a compilation error saying that you cannot access the op_Equality method directly.

Before we proceed, you should probably take a look at the complete method name list from here. If you’ve checked it, then you’ve probably noticed that the table has an extra column, called Name or alternative method. When I said that the C# compiler generated a special method for the operator overload, I didn’t mention one important detail: besides respecting the name defined by the CLR, it will also set a flag in the metadata of the method saying that this is a special method which can be used “as an operator”.

When you’re writing code from  a language which doesn’t support operator overloading, you can still introduce the op_XXX methods. Now, the problem is that you also need to have the special flag applied to that method. If you don’t have it, then you won’t be able to use the operator when consuming the type from, say C#. And that’s one of the reasons why you have the friendly name column in that table. MS recommends that you add those methods when you overload operators so that you can always perform the intended operation (as you might expect, these methods will always redirect to the adequate op_XXX methods). I believe MS could have done better here, but  we have to live with what we have, right? And I guess that’s it for now. Stay tuned for more.

by luisabreu | with no comments

Filed under: C#, Basics

Copy code from VS to Windows Live Writer
Fri, Sep 17 2010 17:06

After a few months of  using the Paste from Visual Studio plug-in for copying code from VS to Windows Live Writer, I think I’ve found something better for this sort of thing. It’s called Paste as Visual Studio Code and I do like the way it works. The best thing  about it is that it’s highly configurable and it does keep the same background you had in VS. If you’re into blogging and you’re using Windows Live Writer and Visual Studio, then you should (a least!) evaluate this plug-in.

by luisabreu | 2 comment(s)

Filed under: Tools

Boxing: when does it happen?
Fri, Sep 17 2010 13:24

In the previous posts, I’ve presented the basics on boxing and unboxing. Today, we’ll take a deep dive into several scenarios which illustrate how boxing/unboxing can occur without you even noticing it. Lets start with a quick recap. Suppose we’ve got the same structure as used in the previous examples:

public struct Student {
    public String Name { get; set; }
    public Int32 Age { get; set; }
}

As we’ve seen, you’ll get a boxing operation whenever you pass an instance of Student to an element which expects a reference type. In other words, the next instructions result in a boxing operation:

Student std = new Student {Name = "Luis", Age = 34};
Object boxedStd = std; //boxing here!

The previous snippet shows an explicit boxing operation. You might need to do this to improve performance. For instance, suppose you need to perform several calls and that all of them expect reference types. Here’s a naive way of doing that:

//all callx methods expect a reference to an Object instance
Call1( std );
Call2( std );
Call3( std );

If you do this, you’ll end up performing three boxing operations (one for each method invocation) because Call1, Call2 and Call3 are expecting to receive a reference type. In these cases, you should probably perform a manual boxing operation before calling those methods:

//all callx methods expect a reference to an Object instance
Object boxedStd = std; //1 boxing operation
Call1( boxedStd );
Call2( boxedStd );
Call3( boxedStd );

With the previous change, we’ve managed to perform a single boxing operation (instead of three). It’s a small improvement, but one that might make a difference when you have lots of calls. Besides method calls, there are other scenarios where you’ll end up with boxing.

If you look at the ValueType type definition, you’ll notice that it inherits from the Object type. So, what happens when you call one of the methods defined by the base class? The answer is: it depends. If you override one of the inherited virtual methods, then the CLR won’t box the instance and you’ll get a non-virtual method call (the CLR can do this since value types are implicitly sealed). *However*, if your override calls the base method, then the value type instance will get boxed because the base method’s this parameter expects a reference type.

When you’re calling a non-virtual method (or a non-overridden method), you’ll get boxing for the same reasons presented in the previous paragraph. There’s still one last scenario where you need to consider boxing. As you know, a struct might implement one or more interfaces. Casting an unboxed instance of a value type to one of the interfaces it implements requires boxing. Take a look at the next example:

public interface IStudent {
    String Name { get; set; }
}
public struct Student: IStudent {
    public String Name { get; set; }
    public Int32 Age { get; set; }
}

And here’s some code which explains where boxing will occur:

Student std = new Student {Name = "Luis", Age = 34};
String nameFromStruct = std.Name;//no boxing here
IStudent stdRef = std;//boxing
String nameFromInterface = stdRef.Name; //gets value from boxed ref

As an extra bonus, do you think you’ll get boxing in the next call? If so, why is that? And if there is boxing, can you do anything to prevent it from happening?

var toString = std.ToString( );

And I think we’ve covered most boxing related scenarios. Stay tuned for more…

by luisabreu | 3 comment(s)

Filed under: C#, Basics

Unboxing: is it really the opposite of boxing?
Thu, Sep 16 2010 23:22

[Update: Thanks to JPC for finding (yet!) another error in my post]

Yes…well, it is, but it’s cheaper (as we’ll see). As we’ve seen in the previous post, we can convert a value type instance into a reference type instance through an operation known as boxing. Unboxing lets you convert a reference type into a value type (if the reference type was originally obtained through a boxing operation, that is). We’ve already seen an unboxing operation in the previous post (though I really didn’t mention it at the time):

var std2 = (Student)cll[0];

In the previous snippet, we’re converting the reference type instance obtained through boxing into a value type instance (notice the cast operator). The algorithm used for unboxing involve the following steps:

1. the first thing required is obtaining the reference type. Then, the reference is checked against null and if it is null, you’ll end up with an exception. If it’s not, then an additional check is performed: the type of the boxed instance is checked. If it doesn’t match the type indicated in the unboxing operation, you’ll get a different type of exception: in this case, an InvalidCastException is thrown.
2. If we reach this step, then the fields values are copied from the managed heap to the newly allocated space in the stack.

Notice that the unboxed value is *always* copied into *newly* allocated space in the stack.  IN other words, in the example of the previous post, we’ve ended up with two different Student instances on the stack. And that’s why you’re wrong if you assumed that the next snippet (also copied from the example in the previous post) would print the value true:

Console.WriteLine(std.Name == std2.Name);

As you can see, unboxing is relatively cheaper than boxing. It goes without saying that boxing and unboxing won’t help to improve the performance of your application, so you better pay attention to your code. Now, that you understand boxing and unboxing, we’re ready for the next phase: understand all the scenarios where boxing happens. Stay tuned for more.

by luisabreu | with no comments

Filed under: C#, Basics

Value types and boxing
Thu, Sep 16 2010 22:39

As we’ve seen, value types have better performance than reference types because they’re allocated in the stack, they’re not garbage collected nor do they get the extra weight generally associated with reference types. There are, however, some times where we need a “reference to  a value object” (yes, I wanted to write “reference to a value object”). In the old days, that would happen whenever you needed a collection of value objects (as you recall, in .NET 1.0/.NET 1.1 there were no generics). Here’s a small example:

public struct Student {
    public String Name { get; set; }
    public Int32 Age { get; set; }
}

Now, and this is important, pay attention to the following snippet:

var cll = new ArrayList();
var std = new Student {Name = "Luis", Age = 10};
cll.Add(std);
var std2 = (Student)cll[0];
std2.Name = "Abreu";

If you look at the docs, you’ll notice  that the Add method expects an Object instance. In other words, it requires a reference type and not a value type. If you go ahead and compile the previous snippet, you won’t get any compilation errors. What’s going on here? What you’re seeing is perfectly normal and it’s called boxing. Boxing allows us to convert a value type into a reference type. Boxing involves a rather simple algorithm:

1. allocate memory on the managed heap for the value object plus the “traditional” overhead space required for all the reference types (btw, I’m talking about the type object pointer and the sync block index).
2. copy the values of the value type’s fields into the heap’s allocated memory.
3. use the returned memory address as the “converted” reference type instance.

When the compiler detected that the Add method requires a reference type, it went ahead and applied the previous algorithm in order to transform the value type and pass a reference into the method. In other words, what got added to the cll collection was the reference obtained from step 3 (and not the std variable).

This has lots of implications which might not be obvious at first. For instance, if you think that the following snippet should print true, you’re wrong:

Console.WriteLine(std.Name == std2.Name);

Before getting into why that happens, we need to understand unboxing. Since it’s 22:37 and I still haven’t had my dinner, I’ll leave the unboxing post for later :)

Stay tuned for more!

by luisabreu | 4 comment(s)

Filed under: C#, Basics

The DOCTYPE element
Wed, Sep 15 2010 22:11

One of things I’ve been doing lately is reading the HTML 5 spec.  Before you tell me to sod off, don’t forger that HTML 5 is here…to stay, I’d say! Yes, there’s still no final version and the RC is only planed for 2012, but  the thing is that most browsers are implementing the current drafts right now.

I’m not sure if you recall the story (or should I say legend?) behind the use of DOCTYPE instructions in HTML pages. Here’s a quick recap: while developing IE 5 for Mac, MS noticed that its new version had improved its standard support so much that it broke most (if not all?) existing HTML 4 pages. Yes, version 5 was better than 4 and there was nothing wrong with (to be honest,  it got several things wrong, but being closer to the standard wasn’t one of them). Yes, the problem was really with the pages, which were written for a specific browser instead of the existing standard(remember the IE4/Netscape 4 browser war?).

We can all agree that MS couldn’t simply break all the existing pages and expect that its authors fixed them (that would surely had cost them the market leadership). So, they had a “great” idea: new pages should use a DOCTYPE directive as a way to indicate that they should be rendered according the spec. If IE didn’t find it in a page, it would assume the so called quirks mode and it would render the page just like IE 4 did. Well, guess what? All other major browsers reused the idea and the DOCTYPE hell was born. If you think I’m kidding, just take a look at Henri Sivonen article on the DOCTYPE instruction…

Anyway, here’s one of several DOCTYPEs which trigger the standard HTML 4 compliant mode in a modern browser:

<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.01//EN" "http://www.w3.org/TR/html4/strict.dtd">

Wtf? Can any of you remember this? I can’t and I’m really scared when I look at Sivonen’s '>table which shows the variety of DOCTYPEs instructions that might (or might not)  trigger the standard compliant mode in the existing browsers…

Thank god the guys behind HTML 5 had simplification as one of their objectives. Now, with HTML 5, you can request the HTML 5 standard mode with this simple DOCTYPE instruction:

<!DOCTYPE html>

How sweet is this? I say it’s great and I *can* really remember this and reuse it in other pages! Thanks guys, I guess I can reduce my daily intake of vitamins :)

And that’s it. Stay tuned for more.

by luisabreu | with no comments

Filed under: HTML 5

Book review: Essential .NET
Wed, Sep 15 2010 19:58

One of the books I’ve re-read during my August vacations was Don Box’s Essential .NET. Tentatively called Essential .NET, Volume I: the Common Language Runtime (I say tentatively because there never was a volume II), it’s really one of those interesting books which you need to read for understanding and having some background on how things worked and on why they were done like this.

The book is starting to show its age (I’ve bought my copy in 2003, if I’m not mistaken) but it still provides lots of value. This is a “Don Box book”, meaning that it’s not for the faint hearted or the novice. If you want to get started then you need to pick another book. This is really a hardcore .NET book about the CLR (like the title says). And being a “Don Box book”, you’ll probably need to read it several times to get the most from it…

The book starts by taking a look at the origins of the CLR and on how it improves the existing state of things (which, if you don’t recall, was COM). After this brief introduction, things start to get really interesting. You’ll start by understanding modules  and assemblies and then you’ll see how the CLR is able to find and load them. Then things get even more interesting as Don goes through the CTS, objects and values, methods, app domains, security and interoperability with unmanaged code.

Overall, and bearing the fact that this is not a beginner’s book, I’m giving it a 9/10 despite its age. 

by luisabreu | 1 comment(s)

Filed under: Books

What about value types?
Wed, Sep 15 2010 19:33

[Update: thanks to Wesner, I’ve fixed the list you should consider when using value types]

In the previous post, I’ve talked about some basic features related with reference types. If all the types were reference types, then our applications would really hurt in the performance department. In fact, hurt is really a kind way of putting it…Imagine having to go through all the hoops associated with creating a new reference type for allocating space for a simple integer…not funny, right?

And that’s why the CLR introduced value types. They’re ideal for simple and frequently used types. By default, value types are allocated in the stack (though they can end in the heap when they’re used as a field of a reference type). Whenever you declare a variable of a value type, that variable will hold the required space for saving a value of that type (instead of holding a reference for a memory position on the heap, like it happens with reference types). In practice, this means that value types  aren’t garbage collected like reference types.

In C#, you create a new value type by creating a new structure (struct keyword) or a new enumeration (enum). Here are two examples:

public struct Student     {
    public String Name { get; set; }
    public Int32 Age { get; set; }
}
public enum Sex {
    Male, 
    Female
} 

Whenever you do that, you end up creating a new type which is derived from the abstract ValueType type (notice that ValueType inherits from Object). Trying to specify a base type for a struct results in  a compilation error.  There’s really nothing you can do about that, so get used to it. Notice, though, that you’re free to implement one or more interfaces if you wish to.  Another interesting thing to notice is that all value types are sealed, making it impossible to reuse them as base  for any other type.

Whenever you create a new enum, you’ll end up with a new type which inherits from System.Enum (which is itself derived from ValueType). There’s more to say about enums, but we’ll leave that for another post.

Creating an instance of a struct is as easy as declaring a variable  of that type:

Student std = new Student();
std.Name = "Luis";

In the previous snippet, we’re forced to used new to make the C# compiler happy. With value types, the new operator doesn’t end up allocating space in heap because  the C# compiler knows that Student is a value type and that it should be allocated directly on the stack (btw, it zeroes all the fields of the instance). Notice that you must use it  (or initialize it in some other way) before accessing its fields. If you don’t, you’ll end up with the “use of unassigned field” compilation error.

Now that you’ve met value and reference types, you might be interested in knowing when to use one or the other. In my limited experience, I can tell you that I end up using reference types in most situations, though there are some scenarios where value types should be used:

• simple, immutable types which behave like primitive types are good candidates for value types. DateTime is probably the best known example of a type.
• “small” types (ie, types which required less than 16 bytes of allocated space) might be good  candidates. Don’t forget method parameters! If the type isn’t passed into methods a lot, then you can probably relax the size rule.

Before you start using value types all over the place, you should also consider that:

• value types can be boxed (more about this in a future post).
• you cannot *should* customize the way these types handle equality and identity.
• you can’t use any other base than ValueType or Enum nor can you reuse the type as a base for another type.
• assigning an instance of a value type to another, you’re really doing a field by field copy. this means that assignments will always duplicate the amount of space necessary.

And that’s sums it up pretty nicely. Stay tuned for more.

by luisabreu | 4 comment(s)

Filed under: C#, Basics

Still on types: reference types
Tue, Sep 14 2010 10:13

Most types introduced by the framework are reference types. So, what is a reference type? Take a look at the following code:

Student std = new Student();

When you instantiate a reference type you end up with a…yep, that’s right: a reference to the instantiated object. Notice that I said reference, not pointer. People tend to use both as synonyms, and that’s ok for most scenarios. However, if you want to be precise, there are some differences between reference and pointers. For instance, reference will support identity checks but, unlike pointers,  it cannot support all comparison operations (for instance, with pointers you can use the < and > operators, but you cannot do that with references).

Reference types are always allocated from the heap and the new operator will always return a reference for the memory that was allocated for that object. If you look at the previous snippet, that means that std will hold a reference to the memory position where the Student object was instantiated. Even though most of the types introduced by the framework are reference types, the truth is that they come with some gotchas. As you might expect, allocating memory from the heap incurs in a slight performance hit. And it might event force a garbage collection if the heap is getting “full”. Besides that, all reference types have some “additional” members associated with them that must be initialized (more on this in future posts).

In C#, all types declared using the class keyword are reference types. Here’s a possible definition for our Student type used in the previous snippet:

public class Student {
    public String Name { get; set; }
    public Int32 Age { get; set; }
}

There still more to say about reference types, but before that, we need to understand value types. Stay tuned for more.

by luisabreu | 2 comment(s)

Filed under: C#, Basics

Grant access to certificate’s private key in IIS 7.5
Mon, Sep 13 2010 12:04

After a bad week (where my work machine died), I’ve finished reinstalling everything. This time, I’ve went with Windows 7 and as a bonus, I’ve ended up with IIS 7.5. One of the things I needed to recover my working environment was to configure access to the certificates’ private keys (I have several WCF services which need certificates). In the old days, the solution was to use the httpcertcfg tool and use the command line.

With IIS 7.5 (also available for IIS running in Vista and Server 2008 with SP2), we’ve got a “new” security feature called application pool identities. According to the docs, application pool identities “allow you to run app pools under a unique account without having to create and manage domains or local accounts”. Until now, everything looks good and this is, indeed, an welcomed new feature. Now, my problem was granting access to the private keys of the certificate to that account. Initially, I’ve tried using my beloved winhttpcertcfg tool:

C:\Windows\system32>winhttpcertcfg -g -c LOCAL_MACHINE\My -s mycertificate -a "IIS APPPOOL\ASP.NET v4.0"

The result: “Error: no account information found.” Not good. I know that I could use the good old FindPrivateKey utility, but I’ve thought that there should be an easy way of doing these things. And yes, there is. I’ve tripped into an even easier way of granting permissions to a private key (interestingly, available since Windows Vista – note to self: start poking around everywhere when new versions of an OS is released!).  Take a look at the following image:

Notice the Manage private keys entry? Yep, that’s just what the doctor ordered! Clicking over that option ends up showing the security dialog and now it’s only a question of adding the correct account (which, if you’re using the new application pool identity, is as easy as writing “IIS apppool\your pool name”). Cool, right?

by luisabreu | 11 comment(s)

Filed under: ASP.NET, IIS

Checked vs unchecked operations
Fri, Sep 10 2010 10:50

In the previous post, I’ve introduced the concept of primitive type and we’ve seen how they’re treated in a special way by the compiler. One interesting topic that pops up when we talk about primitive types is operation overload. For instance, what happens when you try to run the following snippet:

var max1 = Int32.MaxValue;
var max2 = Int32.MaxValue;
Int32 max3 = max2 + max1;

Console.WriteLine(max1 + max2);

MaxValue returns the maximum value that can be stored in an Int32 variable. It’s obvious that trying to save that value into an integer won’t produce the correct result. However, you won’t get an exception if you try to run the previous code. The justification is simple: you see, the CLR offers several IL instructions for doing arithmetic operations. Some, allow overflow to occur silently (ex.: add) because they don’t check for it; others don’t and when that happens, you’ll get an exception (ex.:add.ovf).  As you might expect, the instructions which don’t run an overflow check are faster and those are the ones that are used by default by the C# compiler.

If you want to turn overflow verification for all the code in your assembly, then you can simply use the /checked+ compiler switch. If you’re only interested in checking a specific operator or block of instructions, then you can use the checked operator (there’s also an unchecked operator that does the opposite of that). Here’s a small snippet that shows how you can use these operators:

Int32 max3 = checked( max2 + max1 );

And yes, that should throw an exception at runtime. If you’re interested in running several instructions as checked operations, then the checked statement is for you:

checked {
    var max1 = Int32.MaxValue;
    var max2 = Int32.MaxValue;
    Int32 max3 = max2 + max1;
    Console.WriteLine(max3); Console.WriteLine(max3);
}

Notice that only the instructions placed directly inside the block will be checked, having no direct impact in method calls.

Many people recommend turning the /checked+ compiler switch on for debug builds for detecting problems associated with code where you’re not using the checked and unchecked blocks/statements. You should probably used the /checked+ option for release builds unless you can’t take the small performance hit associated with the use of the aritmethic checks.

Before ending the post, a small note on the Decimal type. You can’t run checked/unchecked operations against the Decimal type because the CLR doesn’t introduce any instructions for arithmetic operations against it. In practice, that means that the special treatment given to the Decimal type is supported only by the compiler (ie, adding too decimals will always result in invoking the Decimal’s corresponding operation method). So, if you hit an overflow during an arithmetic operation, you’ll end up getting an exception (even when you’re using the unchecked operator or the /checked- compiler switch).

And that’s it. Stay tuned for more.

by luisabreu | with no comments

Filed under: C#, Basics

An intro on types: primitive types exist!
Thu, Sep 9 2010 10:53

If you’re not new to .NET, you’ve probably heard several times that one type can be a value type or a reference type. Well, that is true. What people miss (sometimes) is that they’ve also got some data types which are used so often that compilers allow code to treat them in a simplified way: say hello to the primitive types.

Lets look at a small example. Nothing prevents us from writing this code:

System.Int32 myInt = new System.Int32();
myInt = 10;

But does anyone want to write that when they simply can write this:

System.Int32 myInt = 10;

Oh, yes, you can reduce it even further by using the int alias:

int myInt = 10;

Any data type that is *directly* supported by the compiler can be considered a primitive type. Notice the *directly*…it’s used here to indicate that the compiler knows what to do in order to create a new instance from “simplified” code.

Btw, you’ve surely noticed the int alias, haven’t  you? In fact, it’s not really an alias but a C# keyword that is mapped into the System.Int32 FCL type. Even though you can’t introduce new keywords, you can still introduce new alias to simplify the use of certain types. Here’s an example:

using integer = System.Int32;

And now it’s possible to use integer as an alias to the System.Int32 type (btw, I don’t recommend doing this). Currently, there are several types which are treated as primitive by the C#. In that list, you’ll find plenty of numeric types (Int32, Double, etc), strings (String or string – if you prefer the C# keyword), the object (System.Object) type and even the new dynamic type (which, btw, is mapped into an Object instance). As you can see, primitive types aren’t really limited to a subset of value types.

Besides knowing how to create these types, the compiler is also able to perform other interesting operations over them. For instance, it is able to convert automatically between two types without having any relationship between them. Here’s an example:

Int32 myInt = 10;
Int64 myLong = myInt;

Since Int64 and Int32 aren’t “related”, you can only get away with the previous code because you’re using primitive types (and the compiler has privileged knowledge about them!). The C# compiler will allow this type of implicit conversion only when it knows it’s safe (ie, when it knows that there are no data loss during the conversion – which doesn’t happen ion the previous example because you can always save a 32 bit signed integer into a 64 bit signed integer).

For unsafe conversions (ie, conversions where you loose precision), you need to perform an explicit cast. For instance, if you try to convert a Single into an Int32, you’ll need to perform a cast:

Single val = 10.9f;
Int32 myInt = (Int32) val;

In C#, myInt will end up with the value 10 since the compiler will simply truncate the Single’s value. There’s still one additional feature we have with primitive types: they can be written as literals. A literal is *always* an instance of a type and that’s why you can access its type member directly. Here’s an example:

String val = "Hello There".Substring(0, 5);

Finally, the compiler will also let you use several operators against primitive types and it will be responsible for interpreting them. For instance, you can write the following code:

Int32 someVal = 30;
Int32 res = 10*someVal;

There’s still an interesting discussion left (how to handle overflows), but I’ll leave it for a future post. Stay tuned for more.

by luisabreu | 2 comment(s)

Filed under: C#, Basics

Friend assemblies
Tue, Sep 7 2010 10:06

In the previous post, we’ve seen the difference between type visibility and member accessibility. A type can be visible to all the other types defined in the same assembly (internal) or it can be visible to any type, independently from the assembly where it’s defined. On the other hand, member accessibility controls the exposure of a member defined by a type.

By default, internal types cannot be instantiated from types defined in other assemblies. That’s why you’ll typically define your helper types as internal so that they can’t be consumed by types defined in other assemblies. There are, however, some scenarios where you’d like to grant access to all the types defined in another assembly and, at the same time, block access to all the other types defined in other assemblies. That’s where friend assemblies can help.

When you create an assembly, you can indicate its “friends” by using the InternalsVisibleToAttribute. This attribute expects a string which identifies the assembly’s name and public key (interestingly, you must pass the full key – not a hash – and you’re not supposed to pass the values of the culture, version and processor architecture which you’d normally use in a string that identifies an assembly). Here’s a quick example which considers the LA.Helpers assembly a friend:

[assembly:InternalsVisibleTo(“LA.Helpers, PublicKey=12312…ef”)]

As I’ve said before, you *do* need to pass the full public key (if the assembly isn’t strongly signed, then you just need to pass its name). In practice, all the types defines in the LA.Helpers assembly can now access all internal types defined on the assembly which contains the previous instruction. Besides getting access to all the internal types, friend assemblies can also access all of internal members of any type maintained in that assembly.

You should probably think carefully about the accessibility of your type’s members when you start grating friend access to other assemblies. Notice also that creating a friend relationship between two assemblies ends up creating a high dependency between  them and that’s why many defend that you should only use this feature with assemblies that ship on the same schedule. Notice that in my experience, I’ve ended up using this feature *only* for testing helpers that I don’t want to expose publicly from an assembly.

I think that most of us don’t use the command line for building any projects, but this post wouldn’t really be complete without mentioning some interesting details about the C# compilation process. When you’re building the friend assembly, you should use the /out parameter and pass the name of the assembly. This should improve your compilation experience since because you’re giving the compiler what it needs to know to check if the types defined in the assembly can access the internal types of the other assemblies. If you’re compiling a module (is anyone doing this in a regular basis?), then don’t forget to use the /moduleassemblyname parameter to specify the name of the assembly that will contain the module (the reason is the same as the one presented for the /out parameter).

And that sums it up quite nicely (I think). Stay tuned for more.

by luisabreu | with no comments

Filed under: C#, Basics

Type visibility vs member accessibility
Mon, Sep 6 2010 10:19

One of the things I’ve noticed while trying to help others get started with the .NET framework is that they tend to confuse type visibility with member accessibility. In this quick post I’ll try to point out the differences between these two concepts. Let’s start with type visibility.

When you create a type (ex.: class, struct, etc.) it may be visible to all the code (public keyword) or only to the types defined in the same assembly as that type (internal keyword). In C#, you can use the public or the internal qualifier to define the visibility of a type. By default, all the types which haven’t been explicitly qualified with one of these keywords is considered to be internal:

//internal by default
struct T {
  //… 
} 

Member accessibility is all about specifying the visibility of the members of a type. In other words, the accessibility indicates which members might be accessed from some piece of code. Currently, the C# allows you do use 5 of the 6 supported CLR member accessibility options:

• private: members qualified with the private keyword (C#) are only accessible by other members defined in the same type or in a nested type.
• family: members qualified with the protected keyword (C#) can only be accessed by methods in the defining type, nested type or one of its derived types.
• family and assembly: you *can’t* use this accessibility in C#. This accessibility says that a member can only be used by methods in the same type, in any nested type or in any derived type defined in the *same* assembly as the current type.
• assembly: in C#, you use the internal keyword to specify this accessibility level. In this level, the member can only be accessed by all the types defined in the same assembly as the current type.
• family or assembly: in C#, you need two keywords to specify this level: protected internal. In practice, it means that the member is accessible by any member of the type, any nested type, any derived type (*regardless* of the assembly) or any other method in the same assembly as the current type.
• public: members qualified with the public keyword (C#) can be used by any other member in any assembly.

Before going on, it’s important to notice that member accessibility depends always in the visibility of the type. For instance, public members exposed by an internal type in assembly A *cannot* be used from assembly B (by default) since the type isn’t visible in that assembly.

In C#, if you don’t specify the accessibility of a member, the compiler will default to private in most cases (one exception: interface methods are always defined as public!). In C#, when you override a member in a derived type, you must use the same accessibility as defined in the base class. Interestingly, this is a C# restriction since the CLR does allow you to change the accessibility of a member in a derived class to a less restrictive level (ex.: you can go from private to protected in the override, but not the other way around).

There’s still a couple of things I have to say about member accessibility, but I’ll leave it for a future post. Stay tuned for more.

by luisabreu | 2 comment(s)

Filed under: C#, Basics

Partial classes
Mon, Sep 6 2010 9:52

In the previous post, I’ve talked about partial methods and I’ve promised that the next post would be about partial classes. And here it is! Now that I think about it, I should have written this post before the one on partial methods, but this order will have to do it now, won’t it?

The first thing you need to know about partial classes is that they depend entirely on the C# compiler. The second thing you should know is that you can apply the partial qualifier to classes, structs and interfaces (so I probably should have used Partial types for the title of this post).

In practice, when the C# compiler finds the partial qualifier applied to a type (class, struct or interface), it knows that its definition may span several source “groups”, which may (or may not) be scattered across several files. Partial classes are cool for splitting the “functionalities” of a type into several “code groups” (for example, I’ve used it for splitting the definition of a class into several files to improve readability).

Partial types were introduced to solve the same problem I’ve mentioned in the previous post: customization of code built through code generators. Now that you know the basics, lets go through a simple example. Suppose we’ve got a Student type and that you want to separate it’s features into different code groups. Here’s how you can do that with a partial class:

//File Student.cs
public partial class Student {
    public String Name { get; set; }
    public Int32 Age { get; set; }
}
//File Student.Validation.cs
public partial class Student {
    public void Validate(){
        //...
    }
}

In the previous snippet, we’re creating a new type (Student) which is split into 2 different files (Student.cs and Student.Validation.cs). When you compile the previous code (notice that both files must be in the same project!), you’ll end up with a single type (Student) which has all the members exposed by the partial classes.

Even though I’ve put the partial class definitions into different files, the truth is that you can place both in the same file (though I haven’t seen this being used like that in lots of places). Since partial types don’t depend on the CLR but on the compiler, you need to write all the files in the same language and they must be compiled into the same unit (ie, all the partial file definitions must be defined in the same project).

And there’s not much to say about partial types

by luisabreu | with no comments

Filed under: C#, Basics

Partial methods
Sat, Sep 4 2010 23:06

In previous posts, I’ve mentioned extension methods and how you can use them for extending existing types. After talking with a friend, I’ve noticed that I didn’t mention partial methods, which are really useful for code generators. Imagine you’re writing the code generator that needs to generate C# for some specs which are defined through some sort of wizard and that you need to allow customization of some portions of that code. In the “old days”, the solution was creating virtual methods which didn’t do anything and were called by the generated C# code.

Then, the developer was responsible for creating a new class that expanded the generated C# type and for overriding the required virtual methods. Unfortunately, this technique doesn’t really work all the time. For instance, if the generator is creating a struct, you’re out of luck because structs are implicitly sealed!

Btw, and before going on, you should notice that I’ve discarded the option of changing the generated code file because we all know that, sooner or later, something will happen that will force us to regenerate the code again (leading to the lost of all customizations that have been written).

C# 3.0 (if I’m not mistaken) introduced the concept of partial method for helping with this kind of problem. Partial methods work together with partial classes for allowing the customization of the behavior of a method. Here’s a quick example:

//suppose this is generated by a tool
partial class Address{
    private String _street;
    public String Street {
        get { return _street; }
        set {
            if (value == _street) return;
            _street = value;
            OnStreetChanged();
        }
    }
    //always private!
    partial void OnStreetChanged();
}

//dev code for customizing
partial class Address {
    partial void OnStreetChanged() {
        //do your thing here
    }
}

If you wanted, the generated class could have been sealed. Now, customizing the method is as simple as creating a new partial class and implementing the desired partial method. When compared with the virtual method approach I mentioned earlier, there is an important improvement: if you don’t define a custom implementation to your method, then the method definition and call will simply be removed from the source during compilation. In other words, if there isn’t an implementation of the partial method, then the compiler won’t generate any IL for performing that call.

Before you go crazy and start creating partial methods, you should consider that:

• they can only be declared in partial classes or structs (the next post will be about partial classes).
• the return type of a partial method is *always* void and you cannot define any out parameters (understandable since you’re not obliged to implement the partial method).
• a delegate can only refer to a partial method if you define it explicitly (the reason is the same as the one presented for the previous item).
• partial methods are always private (you can’t really apply any qualifier to the method and the compiler ensures that they’re always private).

And I guess this sums it up nicely. Stay tuned for more.

by luisabreu | with no comments

Filed under: C#, Basics

Parameters: oh, I don’t know how many I need…
Fri, Sep 3 2010 11:37

If you’re a long time programmer/developer, then you probably expect to be able to create a parameter that receives a variable number of parameters.In C#, to declare a method that accepts a variable number of parameters you need to qualify the parameter with the params keyword. Here’s a quick example:

static void PrintNames( params String[] names){
    foreach (var name in names) {
        Console.WriteLine(name);
    }
}

As you can see, you use an array to represent a variable number of parameters. Notice that you can only apply the params keyword to the last parameter defined by a method and that parameter’s type must be an array of a single dimension (of any type). When you add the params qualifier, you’re essentially simplifying the invocation code:

PrintNames("Luis", "Miguel", "Nunes", "Abreu");

As you can see from the previous snippet, you don’t need to pass an array to the PrintNames method. If you want, you can create an array and call the method, but I’m thinking that most people will prefer the approach used in the previous snippet.

When the compiler finds the params keyword, it applies the ParamArrayAttribute to that parameter. Whenever the C# compiler detects a call to a method, it will first try to match that calls against a method which hasn’t any parameter annotated with the ParamArrayAttribute.  It will only consider methods with a variable number of parameters (ie, that use the params keyword) when it can’t find a match in the previous candidate list.

Before ending, a performance related note: calling a method with a variable number of parameters incurs in a small performance hit since the compiler needs to transform the list of values into an array (in other words, the method will always receive an array, even though you haven’t built one explicitly). btw, this does not happen if you pass null to the method. And as you’ve seen, it takes longer to find that method because the compiler will first try to find a method which doesn’t use a variable number of parameters. That’s why you’ll find several classes which define several overloads with a variable number of parameters before introducing the method which has a single parameter annotated with the params qualifier (ex.: String’s Concat method).

And that’s it for now. Stay tuned for more.

by luisabreu | 2 comment(s)

Filed under: C#, Basics