LA.NET [EN]

After a great month of vacations, it’s time to go back to work.

And this time, I’ll write a couple of posts about exceptions and exception handing in .NET. In .NET, we should generate an exception when a member (method or property) fails to complete its task correctly. Did you noticed the “fails to complete its task correctly” part? It might be a little bit cryptic, so let’s expand it a little more. Say you’ve got a method which needs to change the value of an integer field as a result of some operation performed over another object it receives as a parameter. There might be some assumptions here…for instance, suppose that that method needs the passed in object to be in a specific state…if that doesn’t happen, then you probably should signal that by generating (ie, throwing) an exception. If you’re consuming that method, then you need to know how to handle an exception. And that is what I’ll discuss in this post.

Let’s take a look at an example…the following snippet illustrates how we can handle exceptions in our code:

Whenever you write code that might throw an exception, it’s a good idea to wrap it up with a try block and specify the exceptions you’re prepared to handle . As you can see, the DoSomething method can recover from the specifics InvalidCastException and AmbiguousMatchException exceptions (notice the use if the catch keyword). Within a catch block, you’ll probably find some logging code which gets and logs information about the current exception. If you’re not able to recover from the exception, then your best option is simply to rethrow the current exception (as it’s shown in the catch all exception block – the third catch instruction). Don’t be tempted to rethrow the exception by writing throw ex;. If you do that, you’ll end up with a new exception stack and the original error stack is lost!

Having said this, there are several choices you can make at the end of the catch block. You can:

1. rethrow the exception (as shown in the global catch block in the previous snippet);
2. create a new (richer) exception and throw it (notice that this is not the same as throw ex; I’ve mentioned before);
3. simply let the thread “leave” the current catch block.

(We’ll return to this in a future post.)

As you probably know, the catch block code will only be executed when the code in the try block generates an exception. When you have several catch blocks (as in the previous example), the CLR will evaluate them from top to botton in the order they were declared until it finds one whose parenthetical expression’s (ie, the expression which appears after the catch keyword) catch type is compatible with the current exception’s type. That’s why you should always put the more specific exceptions at the top.

If the CLR doesn’t find any matching catch code block associated with the try block where the exception was thrown (this doesn’t happen in the previous example because there’s a catch all code block), then it will keep looking in the current call stack until it finds a matching catch block or until it reaches the top of the call stack. In this last case, you’ll end up with an unhandled exception (more about this in future posts). On the other hand, when the CLR finds a matching catch block, then it will go “back” and execute all the “inner” finally code blocks, starting from within the one associated with the try block that threw the exception and stopping in the catch block that is responsible for handling the current exception. At this point, the CLR executes the code of that catch code block and, only then, will it execute the associated finally block code (provided that you don’t rethrow the current exception or throw a new exception from within the last catch code block!).

Notice that the CLR guarantees that the code in the finally block is always executed (even when there’s no exception), making it the appropriate spot for putting your clean up code. I’d say that the typical example of this is opening a file stream and ensuring it gets closed:

The finally block is optional and it must always be defined after all catch blocks (if there are any). After finishing executing the instructions defined in a finally block, the thread will simply jump into the next instruction.

Before ending this post, there’s still time to mention that it’s possible that some code defined within catch or finally blocks might end up throwing an exception. This is definitely *not* a good thing, but it’s also not the end of the world. When this happens, the CLR’s exception handling mechanism I’ve explained in the previous paragraphs will kick in and execute again as if the exception was thrown after the finally block. Notice, however, that all the information about the original exception is completely lost (it’s as if it didn’t happen).

And I guess this is it for now. Stay tuned for more on exceptions.

Post Footer automatically generated by Add Post Footer Plugin for wordpress.

As I write this, I’m getting ready for enjoying month away from my daily job. I hope it’s enough for resting, but what I’d really love is to hear from you, my faithful reader .  I know I haven’t really posted much in these last couple of weeks, but I’ve been really busy updating my HTML5 book (it will more examples which try to illustrate how you can combine several new features introduced by HTML5).

Anyways, I believe it’s time to check if any of the content I’m producing has helped you in any way. When I’ve started blogging, I was working mainly in web projects. That is no longer the case today, though I’m still quite interested in that area. If you’ve been following along, you probably recall that I’ve written about several features/areas (which have ranged from web  to some posts about multithreading in windows). So, would you be interested in keep reading more about .NET basic features? Would you prefer more web? Probably, more posts about JavaScript features? What about multithreading? Some Silverlight love maybe? Or would it be great if I kept writing about several areas?

I’m not really a guru in any of these areas but, as I said, I’ve been working in all of them for quite some time now and probably I can still write one or two interesting entries about them. Thanks for your feedback!

Post Footer automatically generated by Add Post Footer Plugin for wordpress.

Ah, the joy! Almost in vacations, but still one day to go!

We’ve already covered a lot of ground in this delegate series. As we’ve seen, creating a delegate is rather easy: we just need to provide a compatible method and pass it to the delegate constructor which is being initialized. However, there might be times where you don’t have all the required information for creating a new delegate at compile time. Fortunately, our job is not that complicated in these (rare!) cases because the Delegate type introduces several overloads of the CreateDelegate method which helps us in creating new delegate instances at runtime. To illustrate this strategy, we’ll reuse our old Logger delegate definition:

And now, we’re ready to create dynamic delegates…Let’s start with creating a new delegate for the following static method:

And now, here’s how we resort to CreateDelegate to create a new delegate which “wraps” the DoIt static method:

After running the previous code, aux references a Delegate instance. At this point, we have two options: we can cast aux to the correct type (not something you’d be able to do when you’re creating delegates like this) or we can rely on Delegate’s DynamicInvoke method:

DynamicInvoke ends up calling the delegate’s callback method while sending it the arguments it received. Notice that DynamicInvoce will always ensure that the passed in arguments are compatible with the ones expected by the callback method (if they aren’t, you’ll end up with an exception). As you’re probably expecting, there are also other overloads which you can use for creating delegates that wrap instance methods. Suppose we modify our Holder class so that it looks like this:

And here’s how you can create a new delegate dynamically:

And now you can invoke the delegate by executing the DynamicInvoke method like we did before.

Before ending, there’s still time to say that you shouldn’t really use the CreateDelegate overloads which use strings (instead of MethodInfo instances) because there’s a chance of getting an ambiguous binding (and that might lead to unpredicted results).

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

Post Footer automatically generated by Add Post Footer Plugin for wordpress.

I’ve ended the previous post by saying what we can chain several method calls and that is what we’ll see in this post. With chaining, we can combine several delegates so that calling one of them ends up invoking all of them. A quick example is the best way to see this feature in action (I’m reusing the Logger delegate introduced in the previous posts):

I’ve started by declaring three Logger variables which are initialized with three different lambda expressions. After that, I rely on the static Combine method for creating new delegates which “combine” our delegates variables. As you can see, I start by combining del1 with null. When this happens, chain an del1 end up referencing the same memory address. The second Combine call produces more interesting results. Since chain already references a delegate, then this Combine call ends up creating a new delegate whose internal delegate list is initialized with an array that holds the two elements passed to the Combine method.

As you’re probably expecting, the last Combine call will also return a new Delegate but notice that its internal invocation list will have three (not two!) delegate references. You might expect it to have two since our chain variable holds a delegate returned from the second Combine call and you might think that the third call would combine that delegate with del3. However, that doesn’t happen and the last delegate’s internal delegate list will reference our 3 delXXX delegates.  One interesting result of this behavior is that the delegate returned by the second Combine call can be garbage collected since there isn’t any variable referencing it. Btw, you can access this internal delegate list through the GetInvocationList method.

Now, if we invoke chain, all delegates’ methods end up being called. As we’ve seen, calling a delegate through the method syntax is the same as executing the Invoke method. Internally, this method will check the delegate list. When that list is not empty, it will call all delegates present on that list (when the list is empty, it will use the target and method fields for invoking the correct method). You’re probably wondering what happens when our delegate matches a method that returns a value (different from void). Well, in that case, the returned result is the one that is returned by the last delegate that gets executed.

By now, you’re probably thinking that if we can add delegates to the internal list, then we can probably remove them from that list. And that’s true: we can remove a delegate from the list by using the static Remove method. This method expects two parameters: the first references the delegate whose internal list will be searched for; the second identifies the delegate that should be removed from the list ( match is found when a delegate’s target and method fields reference the same objects as the delegate that is passed through the second parameter).

When there are several delegates in the array, the method  will return a new delegate whose internal delegate list has all the remaining delegates. When there’s only one delegate and that delegate is being removed, the method will return a reference to that delegate. It’s also important to understand that Remove will only remove one delegate from the list (even if there are several delegates that match the delegate passed to Remove through the second list). Now that we understand the theory, here’s some code that illustrates the use of the Remove method:

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

Post Footer automatically generated by Add Post Footer Plugin for wordpress.

As we’ve seen in the previous post, delegates are really easy to use: you create a new delegate definition and then instantiate it through the new operator, passing it a compatible method reference. However, there’s a lot more going on behind the scenes and that’s what we’ll start seeing in this post. The first thing we need to understand is what happens when the compiler sees a delegate definition like the one show in the next snippet:

In these cases, the compiler will automatically transform the previous delegate expression into a new class which inherits from MulticastDelegate and looks like this:

Notice that you can’t really reuse the MulticastDelegate type in C# because the compiler won’t allow you to use those classes directly from your C# code.

As you can see, a delegate definition expression ends up generating a new class with a new constructor and three methods: Invoke, BeginInvoke and EndInvoke. Lets start with the constructor. The two parameters it receives are used for initializing, respectively, the MulticastDelegate’s target and method private fields. When we use a delegate to call a static method, the target field is initialized to null. On the other hand, when we use it to call an instance method, the target field is initialized with a reference to the object whose instance member is being invoked. In both cases, the private method field references the method that should be called. Btw, you can access these values through the inherited Target and Method properties:

If you take a look at the MulticastDelegate’s code, you’ll quickly notice that it doesn’t define these properties. In fact, these properties are exposed by the Delegate type, which is used as base by the MulticastDelegate type. To be honest, I really don’t have any good explanation for having two delegate classes since our delegates definitions end up always creating new classes which expand the MulticastDelegate type (and no, you can’t either create a new type which uses Delegate as a base type in C#)…Going back to the snippet, I believe I should mention  that the Method property returns a reference to a MethodInfo instance (this type provides us access to a method metadata – this means you also use it, for instance, to get the name of the method that is being invoked).

Now that we understand what happens when we instantiate a new delegate, it’s type to see how invocation works. So, what happens when the compiler finds something like this:

If we take a peek at the generated IL, we’ll find the following code:

As you can see, our aux method called is translated into an instance Invoke method call. Btw, nothing prevents us from doing that call from our C# text:

And yes, it does compile without any errors (thank you for asking!). Internally, Invoke will use the information returned by the Target and Method properties to invoke the method. As you’ve probably inferred, BeginInvoke and EndInvoke can be used to invoke the methods asynchronously (and have been used for several years as a way to run code in parallel). We’ll probably return to the async methods in a future post…

But there’s more…the astute reader has probably noticed the “Multicast” string in the MulticastDelegate name’s type. It’s obvious that using indirection to invoke a method is really powerful, but what about using a delegate to chain the execution of several methods? We’ll see how we can do this in the next post. Stay tuned for more.

Post Footer automatically generated by Add Post Footer Plugin for wordpress.

If you’re an experienced Windows developer, then you know that Windows has always relied on callback methods/functions for doing several things (ex.: window procedures). In unmanaged code, this was typically achieved through the use of callback functions which, in practice, referenced only a memory address that “had” some code which should be executed when something special happens.

As you probably know, .NET also supports this concept but, unlike unmanaged code, it does it in a type-safe way. As I said, in unmanaged code callbacks reference only a memory position and there’s no extra information about the callback method (for instance, there’s no info about eventual parameters that should be exposed by an eventual callback method). Since .NET tries to enforce type safety, the callback idea couldn’t just be directly ported from unmanaged code: it needed to be improved so that type safety is correctly enforced. And that’s how we got delegates. In .NET, delegates are always created through the use of the delegate keyword. Let’s take a quick look at a simple example:

In the previous snippet, I’ve started by introducing a new delegate (named Logger). As you can see, it’s compatible with methods that return void and expect a String. Then I’ve added a new class which uses the delegate so that it doesn’t rely in a specific class for outputting information about a number (yes, we could also have used interfaces, but lets use delegates this time). By using the delegate, we can now output information to different places by just using a different delegate instance (for example, we can use one for outputting to the console, other for outputting to a file, etc.). Another thing you’ve probably noticed is that delegates are used as methods, ie, we’re using the Logger delegate as if it’s a method from within our class. The next snippet shows how to instantiate a new delegate which outputs info to the Console: 

As you can see, we start by adding a new method which is compatible with the delegate’s signature (notice that ConsoleLogger returns void and expects a string). As we’ll see in the future, we can use static or instance methods (in this case, I’ve opted for a simple static method). You’ve probably noticed that the delegate is being instantiated in a similar fashion to a class. And that’s because it is (but we’ll leave this for a future post). Even though the previous snippet didn’t illustrate it, the truth is that the C# allows for covariance and contra-variance of reference types when binding a method to a delegate. Notice that *reference type* is important here…

Btw, it’s really simple to use delegates to call instance methods, as you can see from the next snippet:

As you can see, the code is really similar to the one we presented earlier. Even though there are several interesting differences in the way both calls are handled internally, there aren’t any from the perspective of the programmer that is using a delegate to call instance or static methods.

Oh, yes, you’ve probably noticed one important difference (when compared with the static method call): I’ve simplified the syntax used for creating the delegate instance. As you can see, I’ve removed the redundant constructor call since the compiler is smart enough for doing that work for me. Btw, and since we’re talking about code simplification, you should also keep in mind that we don’t really need to use named methods and can rely on anonymous methods:

In the previous snippet, we’ve resorted to a lambda expression for creating a method that will be called by the delegate. When the compiler finds this lambda expression, it will automatically translate it into a private static member of that class (notice that the lambda expression doesn’t access any class member!) and replace the previous snippet with a delegate instantiation expression. If our lambda expression referenced any class instance member, then we’d end up with an instance private method.

And I’d say that’s all for now. In the next post, we’ll keep looking at delegates and we’ll see what happens when we instantiate

Post Footer automatically generated by Add Post Footer Plugin for wordpress.

After all, I’ve decided to write another post about custom attributes. In the last post, I’ve mentioned the use of the CustomAttributeData type. Since I’ve received a couple of questions about its use, I thought it would be a good idea to show an example of how one can use this class to check for specific values. So, I’ll just start by introducing the custom attribute and some code that applies it to a property:

In the previous post, we’ve already saw how to check if an attribute is applied to a specific target. So, we won’t be performing that check again and I’ll just show you how to recover the values applied to the properties of the attribute:

I believe the code is rather simple: positional parameters are represented by CustomAttributeTypedArgument instances, which allow us to recover its value and type. On the other hand, named parameters are represented by CustomAttributeNamedArgument instances, where each item exposes a Name (that identifies the custom attribute’s property that is being initialized) and a CustomAttributeTypedArgument property (TypedValue) which allows us to recover its value and type.

And I guess this wraps it up for now! Stay tuned for more.

Post Footer automatically generated by Add Post Footer Plugin for wordpress.

Whenever people ask me what I think about the JavaScript wrapper objects (ex.: String, Number, etc.), I tend to tell them that it’s better to forget that they exist and simply use the literal values (and simply let the runtime perform the conversions between literal an wrapper object automatically and whenever it’s needed). I tend to abide by this rule but today, when I was talking to an old friend, I remember an trick which I’ve learned some time ago which justified the direct use of the wrapper object: I’m talking about (what I call) the wrapper object trick. Here’s some code which illustrates its use:

If you’re a Modernizr user, then you’ve probably recognize this kind of object! No…really? ok, then take a look at the following Modernizr tests:

And now you’ve probably understand what I’m talking about, right? What we’re doing is taking advantage of the fact that Boolean is an object and that means we can add properties to it. If you take a look at the Modernizr source code, you’ll notice that it’ll only create an object whenever it knows that the receiving literal Boolean is true. And there’s a reason for that behavior: since new Boolean ends up creating an object, then a Boolean instance will always evaluate to true in any test. Here’s an example of what I mean:

So, we need to change the code so that it behaves correctly. Here’s how you’re supposed to write the previous snippet:

And now, it all depends on the values you pass to the anonymous function. If you pass it false, then that’s it: you’ll end up with a literal false Boolean. If you pass it true, then you’ll get a slightly modified Boolean object. Unfortunately, I forgot to add this technique to my JavaScript book. If you’ve bought it, please add an URL to this post on section 7.2 …

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

Post Footer automatically generated by Add Post Footer Plugin for wordpress.

Now that we already know how to create new custom attributes and how to restrict its use, it’s time to wrap up this series with a final post that shows how to rely on custom attributes to change the behavior of your code at runtime. One of the first things you’ll need to do (if not the first!) is check for the existence of an attribute. If you have a reference to a type (or can get a reference to a type), then you can perform this check by using the IsDefined method. Suppose we’ve got the following code:

And now, suppose we need to see if the MyAttribute is applied to the Student type. Performing that check is not hard, as you can see from the following snippet:

Both options return the same result (false in both cases). Btw, the second parameter passed to IsDefined is a Boolean which specifies if the attribute should be searched in the inheritance chain. Lets suppose you want to check the if the attribute is applied to a property of the Student class…once again, you can rely on the IsDefined method, but this time, you’ll have to go through each property’s type:

As you can see, the previous code is really similar to the one we had before: the difference is that in this case we’re resorting to LINQ expression to filter the properties to which the attribute has been applied.

There are, however, other interesting options for checking for custom attributes. For instance, the Attribute class introduces several overloads of the following methods (btw, there are several derived Type classes which also expose similar members – we’ve already met the one defined by the PropertyInfo type in the previous snippet):

• IsDefined: returns true when an instance of the specified custom attribute is associated with the target;
• GetCustomAttributes: returns an array where each element is an instance of the specified custom attribute that was applied to the target;
• GetCustomAttribute: returns an instance of the specified attribute if it was applied to the target.

If you’re looking for performance and you’re only interested in checking if a custom attribute was applied to a specific target, then you should use the IsDefined method. This is the most efficient method of the previous list because it doesn’t construct any instance of the custom attribute class. Unfortunately, there are times where you do need to get info about the values of the properties of an attribute class and, in these cases, there’s really no option: you do need to use one of the other methods presented in the previous list. Btw, in these scenarios it’s also a good idea to perform some sort of caching because checking for a specific custom attribute and deserializing it from the metadata tables is not an operation you’d want to perform often.

Before moving on, there’s an interesting gotcha associated with the use of the methods shown in the previous list. The next snippet illustrates this behavior:

And now, what happens if we run the previous property check (which looks for the custom attribute MyAttribute)? It will still return the Name property bacause it is annotated with the MyDerivedAttribute attribute. This might not be problematic, but it’s certainly not what you want if, for some reason, you need to ensure that the type matches only MyAttribute instances (and not its derived types). To get this behavior, you can use something like this:

Until now, I’ve only written code which tests for the existence of a specific custom attribute. Sometimes, you need to check if a specific custom attribute has its properties initialized to some values. There are several options here:

• you can get an instance of the custom attribute and then check for its properties values;
• you create a new instance of the attribute class with the “correct” values and rely on the Equals method which the base Attribute class overrides. Internally, the method will check the type of the attributes and its fields (when both attributes have the same type). Since this comparison relies in reflection, you can improve the performance of the code by overriding this method in your custom attributes so that it doesn’t rely on reflection;
• Besides Equals, there’s also a Match method which you can override for performing more “intelligent” comparisons.

But there’s still more…if you look at the MSDN docs, you’ll find an interestingly named class: CustomAttributeData. If you take a peek at the docs, you’ll notice that it introduces several overloads of the GetCustomAttributes method. In practice, you’ll use this class (and one of its GetCustomAttributes’ overload method) when you need to check for attributes for a type whose assembly was loaded through the Assembly’s ReflectionOnlyLoad method (when you load an assembly through this method, the CLR won’t execute any code in it). In these cases, you do need to rely on this helper class for getting info about its metadata since there’s no way for the code in that assembly to get executed. As you might expect, there are some differences associated with the use of this class…

For starters, the method returns a list of instance of the CustomAttributeData type (one per attribute applied to the “current” target). After getting this list, we can query each instance to determine how the object would be instantiated (ie, check which constructor would be called through the Constructor property) and see which arguments would be initialized (through the property ConstructorArguments). As you’d expect, the approach is slightly different from the one used before. To show a possible  use of this class, lets change the previous code for getting the properties of a type which have been annotated with the MyAttribute attribute:

As you can see, p doesn’t reference an attribute instance but a CustomAttributeData instance. As we’ve said, this means that we need to go through the Constructor.DeclaringType property to get the type of the attribute (which was the only thing we need to do in this scenario).

And I’d say that’s it for now. Stay tuned for more.

Post Footer automatically generated by Add Post Footer Plugin for wordpress.

After another long blogging pause (for a good cause, I must say!), it’s time to go back to our .NET attribute series. In the previous post, we’ve starting looking at how we can build new custom attributes. We’ve already met several restrictions (ex.: inherit from the Attribute base class, limitations applied to the types used as fields, etc), but there’s still one important thing to talk about: how to restrict the members to which an attribute is applied.

By default, you can apply attributes to any member type. This behavior can be controlled through the usage of the AttributeUsageAttribute class. This class introduces several properties which are used by the compiler to check for the proper usage of a custom attribute. The next snippet illustrates its use:

From now on, we can only apply the DumbAttribute to methods and classes. It’s no longer possible to annotate an interface with this attribute. As you can see, the AttributeTargets enum is a flags enum (notice the combination of values) which introduces several constants that identify the application elements to which the custom attribute can be applied to. Currently, this is the only positional parameter that is expected by the AttributeUsageAttribute class. There are, however, several named parameters which are important:

• AllowMultiple: expects a Boolean which indicates that the custom attribute may be applied more than once to an element;
• Inherited: passing true means that the custom attribute will he inherited by derived classes or overriding members.

So, if you need to ensure that a custom attribute is applied only once to a member, you can something like this:

And that’s it. From its use, it’s safe to assume that you’ve probably noticed that AttributeUsageAttribute extends the Attribute class. What you’re probably wondering is what happens when you don’t annotate a custom attribute with an AttributeUsageAttribute instance…well, in this case, you’ll end up with a custom attribute which can be applied once to any type of element and it will also be automatically inherited (and yes, that means that you didn’t really need to explicitly set AllowMultiple to false in the previous snippet).

And I guess it’s all for now. We’ve already covered all the basics associated with custom attribute definition and usage. In the next posts, we’ll see how we can detect their use. Stay tuned for more.

Post Footer automatically generated by Add Post Footer Plugin for wordpress.

In the previous post, we’ve started looking at how we can use attributes to improve the metadata of a type. Even though we’ve looked at some attributes and seen how the C# compiler reduces the required typing by allowing us to skip the Attribute suffix, I didn’t really got into details about how attributes are defined.

In practice, an attribute is always a class. CLR compatible attributes are represented by classes which derive, directly or indirectly, from the Attribute class. Whenever we apply an attribute to a type or member, the compiler needs to create an instance of that type. In fact, you’ve probably noticed that the syntax used for applying an attribute is similar to a constructor call (without the new operator). C# allows us to use a special syntax for setting up properties too. The next snippet starts by creating a new custom attribute and shows how you can initialize its properties in C#:

As you can see, we’ve started by passing the String used for initializing the private name field required by the constructor (since I didn’t specify a default constructor, there’s no way to create a new DumbAttribute instance without passing at least a string!). After that, I’ve initialized the MoreInfo read/write property by using a pair name/value. The docs use different names for identifying these different types of parameters:

• Positional parameters represent parameters passed to the constructor (notice that the order is important here!)
• Named parameters are always defined after positional parameters and allows us to initialize public fields or properties.

When we don’t need to pass any parameters to an attribute instantiation, then we can simply omit the the parameters like we did in the samples shown in one of the last posts:

In C#, there are several ways for us to apply several attributes to a type or member. We can wrap each attribute with its own square brackets ([ ]) or we can use a single pair of square brackets and separate each attribute with a comma. The next snippet shows both approaches:

Before ending, there’s still time for a couple of observations about custom attributes:

1. constructor parameters, fields and properties are restricted to a small set of types: Boolean, Char, (S)Byte, (U)Int16, (U)Int32, (U)Int64, Single, Double, String, Type and Object.
2. You can use single dimension arrays of the previous types (though you shouldn’t use them as positional parameters).
3. Attribute usage in C# force us to use a compile-time constants. In practice, this means that Type “values” are initialized through the typeof operator. Object “values” can be initialized with any value of the list presented in 1 or any other constant expression (you can use null!). Once again, if the expression generates a value type value, it will get boxed at runtime.

These rules are needed due to the work performed by a compiler when it finds an attribute applied to a type or member. When that happens, the compiler needs emit information into the type’s or member metadata table so that it can create an instance of that attribute at runtime (each parameter is serialized before being stored and that is why we’re limited to those types and we can only resort to constant expressions).

In the next post, we’ll see how we can influence the elements to which attributes are applied. Stay tuned for more.

Post Footer automatically generated by Add Post Footer Plugin for wordpress.

To celebrate the release of the new Kinect SDK beta, MS Portugal has launched a new context on the Kinect PT’s Facebook page. To enter the contest,  you need to live in Portugal and send a 140 chars message with an idea for creating something with the new SDK. The two most voted entries automatically  win a Kinect. So will the first one to reach 21 votes…and then, there’s also one available for the best idea (voted by a local Jury). What are you waiting for???

Post Footer automatically generated by Add Post Footer Plugin for wordpress.

We’ve already covered a lot of ground on the basics series…but guess what? There’s still a lot more to cover Today, we’ll start looking at how we can improve our .NET code with attributes. With attributes, we can add custom metadata to our types (and/or a type’s members). After adding extra information to a type (or to a type’s member), you can then query it at runtime through reflection so that you can influence the way some piece of code is executed. Make no mistake about it: we’re talking about some very interesting stuff here! If you don’t believe me, then take a quick look around and you’ll notice  that several .NET technologies rely heavily on it (for instance, it’s used in Windows Forms, WCF, WPF, Siverlight, serialization – oh damn, serialization is also an interesting topic for future posts, don’t you think? – you name it!).

In .NET, anyone can reuse one of the predefined attributes or   just create new one for a specific scenario. Since attributes are targeted at the CLR, then all compatible compilers must understand them, interpret them and add the required entries to a type’s metadata. Before going on, it’s important to understand that most attributes have only one purpose: defining the metadata that will be associated with a type or member. And that’s it. To drive this point home, let’s take a look at the following code:

The first thing you should notice in the previous snippet is that we apply an attribute to a type (or member) through the use of square brackets. In the previous snippet, we’re using the SerializableAttribute to say that Student type instances can be serialized. In C#, you can apply attributes to the assembly, module, types, fields, methods, method return values, properties, events and generic type parameters. Once again, from the previous example, it’s easy to understand that, by default, an attribute is applied to the associated type or member. There are, however, scenarios where you need to use a prefix to make it clear to what you’re applying an attribute to. The next snippet shows how to apply an attribute to an assembly:

Besides assembly, you can also use the module prefix if you intend to annotate the module with a specific attribute and the return prefix if you want to make sure that an attribute is applied to the return value of a method. If you’re targeting the compiler generated field or methods of an event declaration, then you need to use the field and method prefixes:

MyDummy is a custom attribute (we’ll return to this topic in the future). Interestingly, these last two prefixes are optional when you’re targeting a method or a field:

Finally, there  are also the property and param prefixes which can be used to indicate that an attribute is being used to annotate a property or a parameter:

If you’re just starting, then you’ve probably noticed that the compiler allows us to cut the Attribute suffix from the attribute name. This is only possible because the C# compiler team thought that it would be a good idea to reduce the amount of typing and to improve the readability.

And that’s it for now. In the next post we’ll keep looking at attributes. Stay tuned for more.

Post Footer automatically generated by Add Post Footer Plugin for wordpress.

As we’ve seen, we’re limited quite limited when you need to define a new enumerated type: we can only specify the enum base type, the symbolic names and its associated values. That means that you can’t add new instance methods to an enum (which doesn’t really make sense because, as we’ve seen, enums are mapped into structs by the compiler). Fortunately, from C# 4.0 onwards there’s a workaround: we can rely on extension methods for adding methods that are supposed to be used as instance methods.

To  show you how we can improve  our code with utility extension methods, we’ll start by creating a new flags enums (in fact, we’ll simple reuse the Permissions flag enums we’ve introduced in a previous post):

In these cases, it would be really helpful to have a method for checking if a specific bit is on or off. Here’s how we might check that:

And now, we can perform our test as if we’ve added IsBitOn directly to the Enum declaration:

Simple and it works! And now, I’ll leave it to you to think of some cool work which can be done with extension methods Stay tuned for more!

Post Footer automatically generated by Add Post Footer Plugin for wordpress.

Fantastic! Never has an Apple store looked so sexy

Post Footer automatically generated by Add Post Footer Plugin for wordpress.

In the last post, we’ve started looking at the static methods introduced by the Enum type. In this post, we’ll take a quick look at the instance methods provided by that type. Before going into the methods (well, to be precise, I should say method:)), I’d like to make a small detour. I’m not sure that you’ve noticed, but the compiler treats enum as primitive types . In practice, this means that we can use several operators for comparing and manipulating enum instances (I’m reusing the Sizes enum introduced in the previous post):

If you’ve been following along, then you’ve also probably noticed that we can explicitly cast an enumerated type value into a numeric type. Here’s some code that shows this:

And yes, you can also go the other way around:

But there’s more: you can also rely on a cast to convert between different enums types:

And now, back to business…

If you take a peek at the Enum API, you’ll notice that if offers several overloads of the ToString method (we’ll only talk about 2 because the other ones are considered deprecated). As we’ve seen, you can rely on this method to get an enum’s string equivalent representation. The overload that expects a string let’s you pass a value which identifies the format that should be used. Here’s some code that shows how to use this method:

Even though it’s not recommended (or even a good practice!), you can have several symbolic names refer to the same value. In this case, you don’t have any control over which name will be returned when you call the ToString method for formatting the value in the general format.

On the other hand, if there’s no symbolic name for the current value, then the returned string will contain that value:

The behavior of these ToString methods changes slightly when it notices that the current instance is a flags enum. Here’s an example (I’m reusing the Permissions enum from this post):

When the ToString detects the FlagsAttribute applied to the current enum, it treats the current numeric value as a set of bits. In practice, this means that the current numeric value is ANDed with all the enum’s values. For each AND operation that returns true, that value’s associated symbolic name is added to a string and that bit is turned off. If after the end of this algorithm, the final value obtained from the ANDing operation isn’t zero, (recall that each “successful” AND turns off the “associated bits”) then the method knows that there aren’t symbolic names for all the turned on bits of the current numeric value and it will simply return a string with that numeric value.

Btw, if the flag enums has an all “All“ value which matches all the enum’s values and the current value matches that “All” value, then the ToString will return the “All”’s symbolic name. Here’s an example that shows this behavior:

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

Post Footer automatically generated by Add Post Footer Plugin for wordpress.

Since a C# enum declaration is always “transformed” into a struct which inherits from the Enum type by the compiler, then we can reuse those instance methods inherited from Enum and the static ones which expect Enum parameters. In this post, we’ll be looking at the static methods defined by Enum. Lets start by introducing a simple enum which we’ll reuse through the rest of this post:

One of the things you might need is get an enum’s underlying type, which can be done through the static GetUnderlyingType method:

It’s also possible to enumerate the names and values of an enumerated type by using the GetValues and GetNames methods:

You’ve probably noticed the Int64 cast…if you don’t do that, you’ll end up with a string with symbolic name instead. This happens because the GetValues method returns an array which contains one element for each symbolic name of the enum, where each element is an object with the corresponding boxed enum symbolic name’s value.

The Enum class will also let you get the symbolic name of a value by using the static GetName method:

If you’ve got a string, you can try to map it into an enum’s symbolic name through the static Parse method:

In the previous snippet, I’ve used the overload which accepts a Boolean that specifies if the matching should be done in a case insensitive manner (true in the previous example). If Parse can’t match the string to a symbolic name, then it will simply generate an exception. If this behavior is not acceptable, then you should rely on the TryParse method instead.

You can also use the IsDefined method if you want to check if an enum supports a specific value or symbolic name:

As you can see, we can pass a value or a string that identifies a symbolic name. When we pass a value, we must ensure that it has the same type as the one used as the enum’s underlying type. If you don’t do that, then you’ll end up with an exception. Notice also that, unlike Parse, there’s no overload for specifying that the symbolic name matching should be done in a case insensitive manner. Too bad, but that’s life…There’s also a small penalty associated with the internal use of reflection…Finally, it’s important to notice that the method might not work as expected when you pass it a value from a flags enum (where you’ve combined two values). Bottom line: it’s probably a good idea to stay away of this method…

Finally, there’s one more static method: ToObject. There are several overloads of this method (that differ in the expected parameter type) which allow you to convert a value into an enumerated value:

The most interesting thing about this method is that it allows us to pass values of a different type used for the enum’s underlying type. Do notice that there’s also a nasty problem which might get you off guard:

Wow! wtf? Yes, it works. you end up getting a Sizes enum whose value doesn’t have an associated symbolic name. I believe that there are some reasons for allowing this. First, I’m not sure if checking the value would be a reasonable thing to do from a performance point of view. Second, what would be the correct behavior for flag enums? Btw, there’s a similar problem when you initialize a Size enum variable with its default value:

Yes, Default(Sizes) produces a Sizes enum value set to 0. So, if you’re really interested in ensuring that you’ve got a “valid” enum value, don’t forget to check it before converting it into an enum (you can use the IsDefined method or create your own custom routine for doing that check). And I guess this is all for now. In the next post, we’ll take a quick dive into the instance methods inherited from Enum. Stay tuned for more!

Post Footer automatically generated by Add Post Footer Plugin for wordpress.

In the previous post I’ve introduced the concept of enumerated type. As I’ve said, we can resort to an enumerated type to introduce several symbolic names/values pairs. As we’ve seen, enum are transformed into structs which extend the Enum type. During this transformation, the compiler ends up adding constants fields to the struct. By default, ints (System.Int32) are used as the default type for each of these constants. You can change this type by changing the enum’s underlying type:

When the compiler finds the previous enum, it will transform each of the symbolic values into Int64 constants. Besides long, you can also use one of the following primitive types as an enum underlying type: byte, sbyte, short, ushort, int, uint, long, ulong. Notice that (unfortunately!) the compiler forces you to use the C# primitive type name (alias). If you try to use the FCL name, then you’ll end up with a compiler error:

Besides setting the underlying type, you can also be explicit about the values associated with each symbolic name:

As you can see, if you can resort to an attribution if you want to be explicit about the value of symbolic name. If you don’t set a symbolic name’s value explicitly, then it will add one to the previous value (that’s why Sizes.Small has value 11).

Enums can also be used as flags (aka bit flags).  Here’s an example:

In the previous example, we’re using an enum to express a set of bits which can be combined (unlike “normal” enumerated types’ values). Notice also how each symbolic name’s value is defined so that it will only “turn on” a single bit (the comments show the integer represented in binary). In practice, the previous enum allow us to write code like this:

After grabing an enum value, you can check if a specific bit is “on” with code like this:

Even though the previous Permissions enum definition is enough to explain the usage and purpose of flag enums, it wouldn’t be complete without presenting a couple of recommendations associated with its use. So, besides ensuring that each symbolic name’s value will have a single bit turned on, it’s also common to introduce a value called None and the combinations of the most used values. Let’s update our Permissions enum to reflect these recommendations:

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

Post Footer automatically generated by Add Post Footer Plugin for wordpress.

I guess all .NET developers have already used enums (aka enumerated types) in applications, right? if this is true, then you probably know everything there is to know about enums, right? If that is the case, then I’d say you’re can probably miss this and the next couple of posts. On the other hand, if you didn’t have the time to dig into things or if you’re unsure about one or two things, then this series will probably be worth a couple of minutes of your time

Lets start from the beginning, ok? What’s an enum? An enum is a type which defines several symbolic names/value pairs. Here’s a quick example good enough for getting started:

By default, all enum types use ints to store the values associated with symbolic names (this can be changed, as we’ll see in the next post). When you don’t initialize a symbolic name with a name explicitly, then the first name (XSmall) is associated with value 0, the second with the previous value + 1 (in this case, Small is associated with the value 1), and so on. After introducing an enum type, we can simply refer to its symbolic names. Here’s an example of this:

Many see enums as allowing us to mention a value by name (for instance, in the previous snippet, we could see Small as a “synonym” for 1). If that is the case, then are there any advantages in using enum types? The answer is yes, there are several:

• they tend to improve the readability of your code (I believe that Sizes.Small confers meaning which 1 – its associated value – can’t);
• they contribute to easing the maintenance of your code (if you’re using ints, what happens when you need to update 0 to 1?)
• enums are *strongly* typed.

All of the previous reasons are important, but I believe the last one is *probably* the one that makes using enum a *must*. Being strongly typed means that the following code won’t compile:

Enum’s first class treatment gives us a lot of power. But there’s more. All enum types inherit from System.Enum (which inherits from System.ValueType). In pratice, this means that enum types are  value types. However, unlike other value types, you can’t add new methods to an enum directly (like you do when you create new struct). There’s a workaround for this, but the most common case is using inherited methods from the Enum base class (this class introduces several interesting methods which allow us to perform several utility operations over enum values – more about this in future posts).

Even though enum’s usage in C# is rather limited (you can define their symbolic names, values, “base types” and that’s it), it’s probably interesting to end this post by trying to understand how the C# compiler transforms that code into IL. Let’s give it a try, shall we? Let’s take a look at the IL generated for the Colors enum:

As you probably can deduce, each symbolic name is transformed into a const field. In other words, it’s as if you’d written the following C# (btw, don’t try it! You’ll get a compile time error since the C# compiler won’t allow the direct use of the Enum type as a base type):

As I’ve said, you can’t write this last snippet in C#. However, I believe that thinking about this implicit mapping between enum and this pseudocode makes it easy to understand why we can use the instance and static methods introduced by the System.Enum type, right? And I guess this is becoming a rather long post, so that’s all for now. Stay tuned for more on enums!

Post Footer automatically generated by Add Post Footer Plugin for wordpress.

Even though I’ve thought that the previous posts were enough for presenting the Nullable<T> type, the truth is that I’ve received a question about them from a friend of mine. Here’s what he was asking:

If GetType returns T’s type, then how do you know you’re working with a nullable value type?

Nice question…glad you’ve asked about it, though I was saving that part for a future post about reflection. Anyway, the question was asked and I thought I’d give a quick answer here. As we’ve seen in previous posts, Nullable<T> instances have special support and that means that getting the “real” underlying type isn’t really that easy. In practice, we want to ensure this behavior:

Our IsNullable helper method can only return true when it receives a Nullable<T> instance. If, like me, some of your day time is used reading the framework’s code in Reflector, then you’ll probably noticed that there’s a Nullable helper class which exposes several utility methods. One of them is of special interest to us. I’m talking about the GetUnderlyingType method, whose implementation looks like this:

As you can see, the method will return null when it doesn’t receive a Nullable<T> type. It’s also obvious that the method relies heavily in the Type class, which  offers several interesting members that allows us to see if we’re working with a Nullable<T> instance. With this information, it’s time to try to build the first  version of our IsNullable helper method:

hum…you know what? This won’t really work…why? it’s simple: if we write IsNullable(aux.GetType()), we’ll end up with something like IsNullable(typeof(Int32)) and that will always return false. What about changing the declaration of IsNullable so that value is an object reference?

Nop, that won’t work either because the Nullablet<T> GetType “special” method will still produce the wrong results. Going back to the first version of IsNullable, you can see that if we call it like this:

It produces the expected result. So, what we need is a way to infer the type of a variable without specifying explicitly through the GetType call. Is there a way to solve this problem? Yes, there is: enter generic type inference! Here’s our final version of the IsNullable method:

And now, we can call the method by passing it a value:

As you can see, IsNullable relies on the typeof operator for producing the correct result. Another interesting thing is that the IsNullable method doesn’t really use the value var for anything: it’s only there so that the compiler can infer its type. And there you go: a nice trick for checking if a variable is a nullable value type. Before ending, it’s important to give credit to the guy that presented this strategy. I’m talking about Jon Skeet, who presented this code while answering a similar question on the stackoverflow site. And that’s it for now. Stay tuned for more.

Post Footer automatically generated by Add Post Footer Plugin for wordpress.

As you’ve probably noticed, I’ve been a little busy with my new cat. Besides that, I’ve also caught a cold and I’m still lagging in my last work project. Nonetheless, I need to relax and I guess that writing another post on the .NET and nullable value type series is a good way to let off some steam…what can I say?

In the previous post of the series, we’ve seen how C# simplifies the code needed for working with nullable value types (ie, with the Nullable<T> type). If you’ve been using nullable value types, you’ve probably noticed that they don´t really behave like a “normal” value types. This is only possible because the CLR understands that nullable value types are “special” types and gives them special treatment. Here’s a small example:

So, what should the previous snippet print? Int32? Nullable<Int32>? Well, the truth is that Nullable<T> lies and returns Int32 (instead of Nullable<Int32>). This is just one example that shows that Nullable<T> does, in fact, enjoy special treatment from the CLR…but there’s more:

In the previous snippet, we’re initializing someA (which is an object) with aux (nullable value type). If you recall our previous discussions, you’ll remember that putting a value type into an object will always result in a boxing operation. And that’s exactly what is going on here. When the CLR notices that the nullable value type does, indeed, hold a value, it will automatically box that value. When that doesn’t happen (ie, when aux.HasValue returns false), then the CLR won’t do a thing and someA’s value  will be set to null. Grovy, right?

If the CLR can box a nullable value type, then it also needs to perform the reverse operation. In practice, you can unbox a previously boxed T into T or into a Nullable<T> value:

As you can see, unboxing will throw whenever you attempt to convert it to T. That won’t happen when you use T? (ie, Nullable<T>) because we’ve already seen that it’s possible to initialize T? with null. What about interfaces? For instance, if you look at the Int32 type, you’ll quickly notice that it implements the IComparable interface (explicitly). What happens when you need to work to work directly with that interface? For instance, should the following code work?

aux is  a Nullable<Int32> instance and Nullable<T> does not implement the IComparable interface. But Int32 does. If there were no special support from the C# compiler and from the CLR, that would mean that the previous code would, at least, need to perform an explicit cast to Int32 (or access the aux.Value directly). In other words, it would make working with nullable value types a little more cumbersome.

These special support form the CLR makes using nullable value types easy and transparent. And this makes me a happier person…it does…and that’s all for now. Stay tuned for more.

Post Footer automatically generated by Add Post Footer Plugin for wordpress.

Irina is a lovely cat which we’ve picked up from the street. She’s already one year old and I couldn’t resist seeing this beautiful cat abandoned. She arrived last week and I believe she really loves her new home.

Post Footer automatically generated by Add Post Footer Plugin for wordpress.

In the previous post, I’ve introduced the concept of nullable value types. As I’ve said back then, C# allows us to use a simplified syntax for working with nullable value types:

This code is equivalent to the one presented in the previous post. Whenever the compiler finds the XXX? type declaration, it will always convert it into a Nullable<XXX> declaration. But there’s more. I’m not sure if you’ve noticed it, but I’ve initialized the aux2 variable with null. But how can this be if Nullable<T> is a struct? This is only possible because there’s special support for the Nullable<T> type.

Since Nullable<T> instances should behave like Ts, then it’s also possible to apply other “known” operators to these instances:

Isn’t this fantastic? You can also use binary operators with Nullable<T> instances:

When using binary operators, the final result will always be null if one of the instances hasn’t got a “valid value” (ie, if the HasValue property returns false). Finally, you can also check for equality (== and !=) and compare instances (<, >, <=, >=). There is, however, a catch: the code generated for performing these operations is longer than the one you get when you use Ts directly. One final note regarding operators: since T (from Nullable) can be replaced by any struct, then you can create a custom struct and make it “nullable”. Notice that if your custom struct introduces custom operators, then they will be called when you’re manipulating nullable instances of those types! This is simply great!

Finally, and since I’m presenting some C# specific simplifications, I couldn’t end this post without mentioning the null coalescing operator (??). This operator takes two operands. If the one on the left isn’t null, that operand’s value is return. If it is, then the value of right operand is returned. This operator can simplify the code needed for initializing variables:

Before going on, it’s important to understand that the null coalescing operator can also be applied to  reference types. Some say that this operator wasn’t really needed because you could always use the ? : operator. Well, that’s probably true, but there’s one scenario where the null coalescing operator introduces a clear advantage: readability in composition scenarios. Here’s an example:

I’d say that reading this line is easy and simple…And I guess that’s it for now. Stay tuned for more!

Post Footer automatically generated by Add Post Footer Plugin for wordpress.

As I’ve said, a variable holding a value type value can never be null. The justification for this behavior is obvious: the variable contains the value itself (unlike reference types, where the variable holds a reference to another memory location in the heap). And life was fine until someone noticed that it would be really useful to say that value type variable holds value null. “What?”, you say, “that makes no sense!”. And you’re probably right. In theory, there’s no place for null in value types…at least, not until you need to load a value from a database’s table column which is allowed to have nulls…and that’s why MS introduced the Nullable<T> struct. Lets start with some code:

Running the previous code returns the following results in my machine:

There’s already a lot going on in the previous example:

• As you can see, we can initialize a Nullable<T> variable with T or with null (you could also declare a variable without initializing it for getting the same result. I’ve went with the null assignment to simulate getting a value from a data reader).
• The HasValue property returns true when the Nullable<T> private field holds a “non-null” value (ie, when the instance wraps a T value).
• The Value property returns the “current” value type value wrapped by the Nullable<T> instance (notice that the property throws if HasValue is false).
• There’s also a GetValueOrDefault method which returns the current value (when there’s one) or T’s default value when the HasValue property returns false. There’s also an overload of this method which receives a value which is return when the struct doesn’t hold a “valid” value type value.

Nullable<T> is just a lightweight generic struct which wraps a value type field. Besides that field, it will also store a Boolean field which is used for checking if the current Nullable<T> instance holds a valid value. The struct exposes a constructor which receives a T value used for initializing the internal fields. The struct introduces a couple of operators too:

• There’s an *implicit* operator which can transform all T values into Nullable<T> instances (that’s why we can instantiate Nullable<T> variables with the code shown in the previous snippet).
• There’s an *explicit* operator which is able to cast from Nullable<T> to T. Internally, the operator relies on Nullable<T>’s Value property.

Finally, the Nullable<T> struct overrides the Equals, GetHashCode and ToString methods so that you can compare Nullable<T>s and get a string which better represents its state. If you’re a C# developer, then you’ll be glad to know that there’s a simplified syntax for using nullable value types from your code. And that’s what we’ll see in the next post. Stay tuned for more.

Post Footer automatically generated by Add Post Footer Plugin for wordpress.

I’m proud to say that my latest book is out! This time, I’ve decided to write about JavaScript and I tried to cover most features associated with its use. Notice that this isn’t a DHTML book. Instead, I tried to present all the features of this language (including the new ones introduced by ECMAScript5) and introduce several important patterns that are useful in the real world. I can tell you that I had lots of fun writing this books…I mean it! After all, I do love JavaScript. It’s really a fantastic language. It’s a pity that many people don’t use it correctly (but that’s another story…)

Once again, I had the good luck to work closely with my goof friend João Paulo Carreiro. Besides his precious help, I’ve also had important feedback from several other guys:

• Daniel Teixeira
• Carlos Farinha
• Luís F.S. Costa
• Bruno Moniz
• Magno Andrade
• Steven Kimpe
• Helder Robinson

Thanks guys, your feedback was really important for improving the book!

I believe this is book number 8…I’d say it’s time to rest now…I hope…

Post Footer automatically generated by Add Post Footer Plugin for wordpress.

To wrap up this series on .NET arrays, I’ll show you how to create a fixed size buffer (aka internal arrays). A fixed size buffer is useful technique for improving the performance of your app when you need to interop with unmanaged code. To understand the gains from this approach, we’ll start with a simple example:

As you probably know, struct is a value type and that means that it will be allocated in the stack (this is an implementation detail which is important when you’re after performance improvements). Now, what you probably forget is that the Int32 array won’t be stored directly in the stack. Since arrays are reference types, the array field defined in the struct will only hold a reference to the array. The array object will always be stored in the heap memory.

In these cases, sometimes it might be useful to be able to put the entire array in the stack.  We’ve already seen an option for doing this in the previous post. Fixed size buffers allow us to do that too. Here’s some code that shows how to change the previous code so that the array is completely embedded in the struct:

The first thing to notice is that we can only embed an array in an unsafe struct (which, when you think about it, makes sense). If you want, you can apply the unsafe keyword to field (instead of applying it to the struct). Notice also that the array can only be a single dimension zero-based array of one of the basic type (ex.: Int32, Single, etc). Going through all the items of the array can be done in several ways. You can use a pointer or you can simply use the array-like syntax:

As you can see, instantiating a Wrapper will automatically instantiate an array of integers in the stack. As you’re probably expecting by now, you can only instantiate Wrapper from an unsafe context. And that’s it for now. There’s still more to say about .NET basics. Stay tuned for more.

Post Footer automatically generated by Add Post Footer Plugin for wordpress.

I’ve ended the previous post saying that there was still one extra mile we could take to improve the performance associated with arrays in .NET. This extra mile has a name: stackalloc. The stackalloc keyword can only be used in unsafe code and it’s responsible for allocating a block of memory on the stack. In practice, stackalloc creates a single-dimension zero-based array of of value type elements (whose fields’ types are not allowed to be reference types).

There are a couple of things you should keep in mind if you decide to use this option:

• since the memory block is allocated in the stack, then that memory will automatically be reclaimed at the end of the method where it was allocated.
• you won’t be able to pass this memory block to most of the  methods exposed by the types introduced by the framework.

Having said this, it’s time to show a quick sample:

As you can see, it’s not that complicated. The stackalloc keyword is used in place of the new keyword and we end up with a memory block in the stack which is big enough for storing 10 integers.

In the real world, you’ll (probably) use the stackalloc keyword for those scenarios where performance is a must or when you need to use interop to communicate with unmanaged code. In fact, I think that interop is one of those scenarios where stackalloc is a good option.  By using it, you don’t have to allocate an array in the heap (leading to less GC pressure), you don’t have to pin memory (don’t forget that this is a must for passing a reference from a managed object to unmanaged code) and you get automatic clean up on the method’s exit.

Since we’re talking about arrays allocated in the stack, there’s still one more option: fixed size buffers. We’ll take a look at them in the next post! And that’s it for now. Stay tuned for more.

Post Footer automatically generated by Add Post Footer Plugin for wordpress.

In the previous post, we’ve looked an non-zero based arrays and I’ve ended the post by talking a little bit about performance. As I’ve said, non-zero based arrays are not really something you want to use regularly. Besides that, we’ve also seen that regular arrays aren’t as performant as jagged arrays because the compiler won’t, for instance,  hoist the index checking outside an eventual loop. Since this index hoisting *does* make a difference, then how can we improve the performance of our code? Well, there is a way for improving the performance, at the coast of safety: I’m talking about using unsafe code for enumerating the items of an array!

When you use this strategy, you’re performing a direct memory access. Notice also that these accesses won’t throw exceptions when you access an “invalid position” (like it happens when you use the “traditional approach”). Instead, you might end with a memory corruption…

In practice, using unsafe code means that the assembly that contains this code must be granted full trust or have the security permission’s skip verification option turned on.  After this basic intro, it’s time to see some code. The next snippet introduces two methods which go through all the items of a rectangular array by using a safe and an unsafe approach:

There’s not much to say about the SafeAccess method. There are, however several interesting observations about the UnsafeAccess method:

• the method is marked with the unsafe keyword because it uses pointers to access the items on the array (don’t forget that you need to compile this code with the /unsafe option).
• ptr is a pointer which points to the memory address of the first item of the array.
• We’re fixing (or pinning) the pointer (by using the fixed statement) to prevent the GC from reallocating a movable variable (since the ints references a managed array, it could get moved during a GC compaction operation).
• We need to perform the calculations required to access the items of the array. Even though we’ve got a rectangular array, the truth is that it is allocated as single block of items, where one line is appended to the end of the previous one.
• Finally, notice that we get the value of each value by using an “array index syntax” (similar to the one used in traditional C# code and to the one you can use with unmanaged C or C++)

In my machine, running the previous code resulted in the following output:

As you can see, there’s a small difference which can make all the difference in the world for those apps  where you do need that extra performance ounce…Before ending, a couple of observations:

• as I said, this code needs full trust and there might be some places where your code won’t have it.
• This strategy can only be used for arrays which hold primitive types, enums or structs whose fields’ type is one of the previously mentioned types.

If you want, there’s still an extra step for improving the performance of code that interacts with arrays, but that will be the topic of the next post. Stay tuned for more.

Post Footer automatically generated by Add Post Footer Plugin for wordpress.

Today I’m going to to something which I really don’t like: I’m going to show you how to create non-zero lower bound arrays (aka, non-zero-based arrays). Before going on, I must say that I find it hard to justify the creation of these types of arrays. Anyways, since I’m covering arrays, I guess I must really show some code that illustrates its usage in C#. The Array class offers a static CreateInstance method which we can use to create arrays. There are several overloads, but we’re interested in the one which allow us to specify the lower bound and number of elements in each dimension. The following snippet shows how to create a single dimension array which can hold 2 elements on positions 10 and 11:

As you can see, the CreateInstance method receives three parameters:

• The first, identifies the type of each item that will be stored in the array.
• The second is an array which indicates the number of elements stored in each dimension. Since we only have one one dimension, we pass only the number of items for that single dimension.
• The third parameter identifies the starting index (ie, the lower bound) of each dimension (in this case, the array starts at index 10).

Internally, the CreateInstance method will allocate enough memory for the array, it will also keep the information about the bounds and dimensions and it will return an Array instance. As you can see, returning an Array instance means using the instance GetValue and SetValue methods for reading and writing values to our array…at least, that’s what we need to do in C#. Interestingly, we can use the traditional syntax for accessing items of a multi-dimension non-zero-based array:

If you’re creating arrays where you don’t control the lower and upper bound indexes, then you should probably resort to the GetUpperBound and GetLowerBound methods. In the next snippet, I use these methods for enumerating all the items stored in the ints array:

As I said, using non-zero-based arrays is one of those things you shouldn’t really do. For starters, they have worst performance that the traditional zero-based arrays. And there are several reasons that justify this behavior. In fact, if you’re after performance, then you should use only single-dimension zero-based arrays. For starters, there are special IL instructions that the compiler uses for accessing items in these arrays that will make the JIT emit optimized code. When you’re using a single dimension zero-based array, the JIT can hoist the index checking code in loop, making that validation run only once, at the beginning of that loop.

This hoisting optimization doesn’t happen with non single dimension zero-based arrays (in practice, this means that each array item access will only be allowed after checking if the specified index is valid). Besides that, the JIT will have to subtract the array’s lower bound position to the specified index to get the item you’re requesting (notice that this is also done for multi-dimension zero-based arrays). These issues make me believe that using non-zero based arrays in .NET isn’t really a thing which you want to do often. And I have done just that in these last years…

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

Post Footer automatically generated by Add Post Footer Plugin for wordpress.