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: ,
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: ,
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: ,
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: ,
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: ,
What’s next?
Thu, Sep 2 2010 20:43

After almost a month of vacations, I’m back (you’ve probably noticed that I’ve resumed my basics series)! This year I had a really cool time in my vacations. I’ve stayed almost a week in Milano (here are some pics), I’ve managed to go to the beach several times (something that didn’t happen in these last 5 years) and I’ve sold my Peugeot (I guess I’m already missing it, but not its assistance) and bought a Smart. And it all ended with a great weekend at Calheta Beach hotel.

But alas, it ended! so I guess it’s time to start thinking about what I’ll be doing next. The Silverlight book is practically wrapped up, so that means I’ll be writing more here (or at least, I’ll be trying to do that). I want to continue my basics series because it’s being fun and it’s responsible for making me remember (and learn) stuff I’ve completely forgotten (or didn’t even knew that existed). I also intend to start digging into HTML 5, so I’ll probably be writing something on that too. btw, if you want to suggest a blogging topic, this is your cue!

A final note: it’s becoming increasingly harder to go back to work…does that mean I need to start thinking about a new job? hum…I probably should…

by luisabreu | with no comments
Filed under:
Parameters by reference
Thu, Sep 2 2010 10:28

By default, parameters are always pass by value. However, the CLR does allow you to pass parameters by reference. In C#, you can use the out or ref keywords for passing parameters by reference. When the compiler sees that you’ve used these keywords, it will emit code that passes the *address* of the parameter rather than its value.

Interestingly, these two keywords are identical from the CLR’s point of view. The story is completely different for the C# compiler since it uses them to see who is responsible for initializing the value of a variable. Using the *ref* keyword is the same as saying that the caller is responsible for initializing the value of the parameter. On the other hand, using the out leaves that responsibility for the method. Here’s some really simple (dumb) methods:

static void ChangeNameWithOut(out String name){
    name = DateTime.Now.ToString();
}
static void ChangeNameWithRef(ref String name){
    name = DateTime.Now.ToString();
}

Now, here’s how you can use both methods:

String name = "Luis";
String anotherName;
ChangeNameWithOut(out anotherName);
ChangeNameWithRef(ref name);

As you can see, you’re not initializing the anotherName method before passing it to the ChangeNameWithOut method. If you tried to pass anotherName to the ChangeNameWithRef method, you’d end up with a compilation error: Use of unassigned variable ‘anotherName’.

You’ve probably noticed that you’re forced to use the ref and out keywords on the call. For a long time, this puzzled me and I thought that the C# compiler should be able to infer that from the call. According to Jeffrey Richter, the designers of the language felt that the caller should make their intentions explicitly. I’m not sure I agree with that, but it’s just the way it is. And, as we’ll see next, this decision allows to overloads methods based on these keywords.

You can use the out and ref parameters for overloading methods, though you cannot add two overloads that differ only in out or ref only. Here’s some code that illustrate these principles:

static void ChangeName(String name){}
static void ChangeName(ref String name){} //ok
static void ChangeName(out String name){} //error

Adding the first overload won’t lead to a compilation error because you can overload methods by using the ref or out keywords. Adding the last method leads to a compilation error because you cannot add an overload that differs only by out and ref.

Besides overloading, there are some gotchas when you use reference parameters. Here’s a small example that might catch you off guard:

static void DoSomething(ref Object someParameter){}
var str = "Luis";
DoSomething(ref str);

You can’t compile the previous code. If you try, you’ll get an error saying that you cannot convert from ‘ref string’ to ‘ref object’. In other words, the parameter’s type must match the type of the value that is passed. In case you’re wondering, this is needed to ensure that type safety is preserved. The next snippet shows why this is a good thing:

static void DoSomething(ref Object someParameter){
    someParameter = new Student();
}

And I guess this sums it up nicely. There’s still some more about parameters, but we’ll leave it for future posts. Stay tuned for more.

by luisabreu | with no comments
Filed under: ,
Parameters: by value or by reference? Say what?
Wed, Sep 1 2010 20:33

I’m guessing that I won’t be giving any news when I say that parameters are used for passing values into methods. By default, parameters are passed by value. Here’s a quick example which will let us discuss this behavior:

public class Student {
    public String Name { get; set; }
    public Int32 Age { get; set; }
}
static void ChangeName(Student std) {
    std.Name = DateTime.Now.ToString()
}

As I was saying, parameters are passed by value. And that’s true. However, many still are surprised when they discover that ChangeName will update the Name of the Student’s instance that was passed into the method. How can that be? Isn’t passing by value the same as “copying”? Well, that is absolutely correct. What you must keep in mind is the *type* of variable you’re passing into  the method.

In my previous instance, Student is a reference type. What that means is that a variable of that type will reference some memory space, which is where the values of its fields will be stored. Now, even though I don’t like to talk about implementation details, I’d say that they help (at least, in this case). Lets suppose we’ve got some variable std:

var std = new Student { Name = "Luis", Age = 34 };

Now, you can think of std as holding the memory address where the Student object was allocated. When you look at if from this perspective, things might start to make sense, right? Suppose you’ve got the following code:

ChangeName(std);

Since ChangeName’s only parameter is passed by value, you should be able to see what’s going on. The value of the std variable is copied to th the std parameter and that means that the std will hold a memory address. When the ChangeName starts  executing, there are two “variables” pointing at the same “memory location”: the parameter and the variable which was passed into the method through that parameter. That’s why if you try to change the  value of the std parameter (ie, make it reference another instance of Student), that change won’t be replicated outside the method (notice that changing the value isn’t the same as changing the property of object to which the parameter “points” to). Here’s a quick example of what I mean:

static void ChangeName(Student std) {
    std = new Student { Name = "John", Age = 40 };
}
var std = new Student { Name = "Luis", Age = 34 };
ChangeName(std);
Console.WriteLine(std.Name);//prints Luis, not John

See the difference? If the std parameter was passed by reference, then the std variable would point to the new Student instance allocated inside the method. If you run the previous code, you’ll see that that doesn’t happen.

How, then, can we change this behavior? Simply by indicating that the parameters should be passed by reference. We’ll see how in the next post, so stay tuned!

by luisabreu | 2 comment(s)
Filed under: ,
Extension methods: what, how, when
Tue, Aug 31 2010 10:02

I’ve already written a little bit about extension methods in the past. However, since I’ve decided to create a new basics series, I think that I probably should go back and write about it again. I guess that the first thing I need to do is define the what. In other words, *what* is an extension method?

An extension method is a static method that you can invoke using instance method syntax. Here’s a quick example:

namespace StringHelpers {
    public static class StringExtension {
        //don't need this in real world!!
        public static Boolean ContainsOnlyDigits(this String str){
            if(str == null ) throw new NullReferenceException();
            return str.All(c => char.IsDigit(c));
        }
    }
}
//use the extension method
namespace ConsoleApplication1 { //import extension methods using StringHelpers; class Program { static void Main(string[] args){ var notOnlyDigits = "123Nop"; //const is better Console.WriteLine(((String)null).ContainsOnlyDigits()); } } }

As you can see, an extension method is always static and must be defined in a non generic, non nested, static class. The first parameter of an extension method is annotated with the this qualifier and defines the type over which the method can be called using an instance method syntax. In order to use the extension method (the *how*), we must first introduce it in the current scope. To achieve that, we need to resort to the using directive (as shown in the previous example).

Whenever the compiler finds an extension method, it will convert it into a static method call. Currently, you can use extension methods to extend classes, interfaces, delegates (probably more about this in a future post) and enumerate types. Internally, and since external methods aren’t C# specific, there is a “standard” way to mark a method as an extension method. In C#, when you mark a static method’s first parameter with the this qualifier, the compiler will automatically apply the ExtensionAttribute to that method and to the class where that method is defined. By annotating the type with the attribute, the compiler is able to query an assembly and get all the types that have extension methods defined.

Extension methods are really great and do improve the quality and readability of the code. However, I’ve noticed that they’re starting to be abused…for instance, it was only recently that I’ve downloaded the source code for the Fluent NH project and I couldn’t stop noticing that the CheckXXX methods (used against PersistenceSpecification instances) are all implemented as static methods. I’m having a hard time understanding this and here’s why. In my limited experience, PersistenceSpecification exists so that you can write tests for your NH mappings. Now, that means that you’ll *be* using this methods to test the mappings whenever you instantiate a new instance of that type. Since the guys that wrote the code for those methods *do* have access to the PersistenceSpecification class, I really can’t understand their decision of defining these methods as extension methods (and yes, I know that MS used the same approach for extending the IEnumberable<T> interface, but I believe that we’re not talking about the same type of scenario: after all, it’s perfectly fine to use the IEnumerable<T> without using LINQ).

So, when should we use extension methods? Here’s my thoughts about it (the *when*):

  • use it *sparingly*. I really can’t stress this enough! We’re still doing OO and there are several options for extending types. Do remember that there are some versioning problems associated with extension methods. For instance, if the type you’re “extending” adds a new method with the same name as the extension method, the code will always use the instance method (after recompilation, of course) because extension methods will only be considered as candidates when all the instance method available have been considered as non-viable.
  • they should look and feel like extension methods. The typical example of not following this recommendation is adding an IsNullOrEmpty extension method to some class and returning true when the “this” parameter is null (btw, here’s an example of what I mean). If the “this” parameter of the extension method is null, it should really throw a null reference exception since this is the best option for mimicking what happens with instance methods.

Overall, I’d say that extension methods are an excellent tool, but don’t get carried on and start using it everywhere. After all, we’re still writing object oriented code, right?

by luisabreu | 2 comment(s)
Filed under: ,
Hello Froyo!
Sun, Aug 1 2010 19:37

The wait is finally over: Froyo is here (at least, for all HTC Desire models). The install went really well and it involved a couple of reboots and was not as along as I expected. I’ve already noticed some improvements in the OS (for instance, you can now switch between languages in one key stroke while writing – which is really cool if you need to write in different languages like I do). I’ve also used the free Quadrant Benchmark app and I’ve seen several improvements (when compared with the previous version).

I’ve also decided to go ahead and installed the Java and the Android SDK in my laptop. It’s a x64 machine, so I’ve faced a couple of problems related with installing x64 JDK and making it play nicely with the Android x86 SDK. As always, Stackoverflow was a good help and I managed to set everything up in just about 10 mins. Btw, I did try to use eclipse and the Android SDK from my netbook, but the damn thing almost froze the machine, so I had to test it in my laptop. I think that I’ll be using my netbook only for C# code from now onwards…

So, now I should be able to run a few dumb apps to see how difficult it is to write an Android app (the only thing I need is some spare time :( ).

by luisabreu | 2 comment(s)
Filed under:
Quote of the day
Wed, Jul 21 2010 19:29

While I was reading the Dive into  HTML 5 book, I’ve found this pearl of wisdom:

Originally, all AAC files “bought” from the iTunes Store were encrypted with Apple’s proprietary DRM scheme, called FairPlay. Selected songs in the iTunes Store are now available as unprotected AAC files, which Apple calls “iTunes Plus” because it sounds so much better than calling everything else “iTunes Minus.”

LOL…

by luisabreu | 1 comment(s)
Filed under:
Back to the basics: more on casting
Wed, Jul 21 2010 14:54

I’ve already mentioned casting several times before, but I guess I’ve jumped over several basic features associated with that operation. Since this is a basics series, I should have probably explained casting instead of assuming that everyone knows how it works. So, I’ll go back and use this post to present some features associated with casting in C#. By default, the CLR allow us to cast an object to its type or to any of its base types. If you’re using C#, then you don’t need to do anything to cast an object to any of its base types. Take a look at the following code:

class A { }
class B : A { }
class Program {
    static void Main(string[] args){
        var b = new B();
        A a = b;
    }
}

The example is simple: we have two types, where one type (B) extends the other (A). As you can see, we can cast the variable b to the type A without using any special syntax. C# will also let you go from an A to a B (but only if that A is-a B). Take a look at the following snippet:

var a = new A();
var b = new B();
A anotherA = b; //ok
B anotherB = (B) anotherA; //also ok
B stillAnotherB = (B) a;//oops: InvalidCastException

As you can see, “going” from A to B is possible, but only when we’re talking about an instance of type B (or derived from B). The CLR will always ensure at runtime that the cast works and it ends up throwing an exception when that cast is not possible (and when you don’t define a conversion operator that allows the conversion between those types).

Why does the CLR enforces this rule? One of the corner stones of the CLR is type safety. In practice, this means that at runtime the CLR always knows the type of each instance of an object. If the CLR allowed casts without enforcing these rules, then  you could end up with unpredictable code that could cause security breaches in an application. I’m not sure if you’ve noticed but a type can’t spoof another type at runtime because the method that returns the type of an instance (GetType) is not virtual. Since it’s not virtual, you cannot override, so casting an object to Object and calling the GetType method over that instance will always return an object’s true type (even in those cases where you use the new keyword to “redefine” a method). Here’s some code that illustrates this technique:

class A { }
class B : A {
    public new Type GetType(){
        return typeof (A);
    }
}
class Program {
 static void Main(string[] args){
  var b = new B();
  Console.WriteLine(((Object)b).GetType());//prints DemoProj.B
  Console.WriteLine(b.GetType());//ATTENTION:prints DemoProj.A
 }
}

Do notice that if you don’t cast the variable to object (btw, this cast always succeeds), then you’ll end up getting a spoofed type. And that’s it. Stay tuned for more.

by luisabreu | with no comments
Filed under:
Back to the basics: conversion operators
Mon, Jul 19 2010 15:18

[Update: small update to the implicit operators code. Thanks Kevin]

In a previous post, I’ve mentioned conversion operators. But what is a conversion operator? In the past, I bet that we’ve all needed to convert from one type of object to another. When we’re talking about primitive types, the CLR knows how to perform the conversion (of course, when that is possible). However, when we’re not talking about primitive types, the CLR is only able to perform the conversion if the source object’s type is the same as (or derived from) the target type.

There are other scenarios where we’d like to convert from type A to type B but these types aren’t related. Since the types aren’t “related”, we can’t simply cast from one type to another. In these cases, we’re limited to adapting the API of our types so that they ease the “translation” between types. For instance, suppose we’ve got the following class:

public class A {
    private Int32 _someState;
    public A(){
    }
    public A(Int32 someState){
        _someState = someState;
    }
    public Int32 ToInt32(){
        return _someState;
    }
}

By writing this code, we can “convert” an integer into an A instance (through the constructor) and we can also get an integer from any A instance (by calling the ToInt32 method). Here’s an example:

var fromInteger = 10;
var someInstance = new A(fromInteger);
var wrappedInteger = someInstance.ToInt32();

Defining the methods presented in the class is really a good idea because it means that your class can be consumed from any .NET language. Now, if you’re writing code in a language like C# which supports conversion operators, you can take this a little further and create you own customized conversion operators. The idea is to be able to write code like this:

var fromInteger = 10;
var someInstance = (A)fromInteger;
var wrappedInteger = (Int32) someInstance;

The previous snippet is using an *explicit* conversion operator for converting from and to an integer. An explicit operator is define by a special public and static method where the return type or the parameter must be of the same type as the class where it’s being declared. In order to make the previous code compile, we need to add the following methods to our type:

public static explicit operator A(Int32 anInteger) {
    return new A(anInteger);
}
public static explicit operator Int32(A anA){
    return anA.ToInt32();
}

As you can see, I’ve implement both methods by using the constructor and helper method previously added to the class.  As you can see, both methods return an instance of type A or receive a single parameter of type A. Notice also the use of the explicit keyword.

By annotating our conversion operator methods with that keyword, we’re saying that the compiler is only allowed to use them when it finds an explicit cast. There is also another option here: we can create an implicit conversion operator. We should create an implicit operator whenever there’s no precision lost during the conversion. In our simple example, that never happens, so we can add implicit operators to our classes:

public static implicit operator A(Int32 anInteger){
    return new A(anInteger);
}
public static implicit operator Int32(A anA){
    return anA.ToInt32();
}

Since the implicit and explicit keywords aren’t part of the method signature, then you can’t simultaneously define an explicit and implicit operator for the same type. After adding the operators, you can now run the following code without any errors:

var fromInteger = 10;
A someInstance = fromInteger;
Int32 wrappedInteger = someInstance;

I have used conversion operators in the past and they have improved the readability of my code. For instance, they’re useful when you’re using a fluent builder to create a new instance of a type. Since conversion operators are methods, I guess it would be nice to see the final result of our C# code. Implicit cast operators end up generating methods named op_Implicit, while explicit convertors end up generating op_Explicit methods. Here’s the signature of the IL generated for the implicit operators:

.method public hidebysig specialname static int32 op_Implicit(class DemoProj.Program/A anA) cil managed
.method public hidebysig specialname static class DemoProj.Program/A op_Implicit(int32 anInteger) cil managed

We could, of course, improve our code and add other operators. For instance, lets add an explicit Single conversion operator:

public static explicit operator Single(A anA){
    return anA.ToInt32();
}
public static explicit operator A(Single aSingle){
    return new A((Int32)aSingle);
}

And now, we can write the following code:

var single = (Single) someInstance;
var anA = (A) single;

If you’ve been paying attention and you’ve been writing C# for some time, you’ve probably noticed something strange. How can we write two methods which only differ by return type?

I’ve already said that the explicit/implicit keyword isn’t used in the method signature, but “just to be sure”, you can go ahead and make all conversion methods explicit. After performing this small change, you’ll end up with two methods which differ only in the return type (the explicit convertors from A to Int32 and Single). What’s going on here?

Unlike C#, the CLR does allow you to overload based on the return type. So, if you’re writing IL (anyone?), then you *can* overload methods by return type (though this really isn’t recommended because you won’t be able to consume those types from C#). The C# compiler uses this knowledge and allows you to introduce these overrides when you’re writing operator convertors.

Before ending, you should also notice that there are some things to keep in mind before creating and using conversion operators:

  • you cannot create custom conversions for interfaces or for the Object type.
  • conversion operators are not executed when using the is and as operators.

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

by luisabreu | 1 comment(s)
Filed under:
Back to the basics: type constructors
Thu, Jul 15 2010 20:48

After the last two posts, I guess you could see this coming, right? Today it’s all about type constructors (and it’s a long post, so make sure you’re comfy). What is a type constructor (aka, class constructor)? In C#, it’s a static and private parameterless method which is named after the class where it’s defined. Here’s a small example:

class MyClass {
    static MyClass() {
        //initialize static fields here
    }
}

Type constructors must be private (in fact, in C# you can’t even use  that qualifier or the compiler will start complaining) and can’t receive any arguments. In practice, this means that you can only have one type constructor. Typically, you’ll be using type constructors to initialize static fields. Here’s an example:

class MyClass {
    private static Int32 _myField;
    static MyClass() {
        _myField = 10;
    }
}

If you’re just initializing static fields with “simple” expressions, then you can use the same technique I’ve shown you before for instance constructors. In other words, you can use static field initialization:

class MyClass {
    private static Int32 _myField = 10;
}

When the previous class is compiled, you’ll end up with code that is identical to the first snippet. To be sure, you can always fire up Reflector and see what’s the generated C#:

reflector

The previous image shows another interesting thing: type constructors are always named .cctor in the metadata table which contains the methods definitions of a type. Notice  that the C# compiler will never generate a type constructor automatically when the class doesn’t have any static fields which use the initialization “trick” I’ve mentioned above. Another interesting caveat is that type constructors don’t call the base type constructor (if it exists, that is). Here’s some  code that shows this:

class Program {
    static void Main(string[] args) {
        Console.WriteLine(MyDerived.SomeField);
    }
    class MyClass {
        static MyClass(){
            Console.WriteLine("MyClass");
        }
    }
    class MyDerived:MyClass{
        public static Int32 SomeField = 10;
        static MyDerived()  {
            Console.WriteLine("Derived");
        }
    }
}

When I first notice this, I was  a little bit surprised since that “seems” to go against what’s expected. Anyway, it works this way and that’s that. I was also surprised the first time I got a TypeInitializationException when trying to instantiate a new variable of a specific type. After some debugging, I’ve noticed that my type constructor was generating an exception which was being silently caught (poor coding, I know) before I tried to instantiate an object of that type. What I’m trying to say is that if your type constructor throws, then you can no longer instantiate an instance of that type in the current AppDomain.

Type constructors do have more surprises…Type constructor invocation is injected on the fly by the JIT when it detects that a “piece” of code is trying to access a type which has a static constructor that hasn’t been invoked yet. Since the CLR guarantees that a static constructor is executed only once (per AppDomain), then the thread that calls it does it from within a lock. Even if there are multiple threads trying to execute the constructor, only one will be able to call the type constructors while the others wait for the lock.

When the lock is released, they will notice that the type constructor has already been invoked and won’t call them again. Things can get a little complicated when you have two static constructors of different classes that “reference” each other. Interestingly, the CLR does ensure that both static constructors are called, but it can’t guarantee that one type constructor is run to completion before the other is executed.

But there’s more! As I’ve said, the JIT needs to decide where to insert the static constructor call when it notices that some piece of code is trying to access a member of a type which defines a static constructor. This makes sense, but it was only after reading Jeffrey Richter’s fantastic book that I’ve managed to get a clear picture of what’s happening. 

The static constructor call can be made *immediately* before some piece of code that creates an instance of that type or accesses a member of the type. Another option is to  guarantee that the call will be made *sometime* before one of those things happen. These two strategies are known as precise semantics and before-field-init semantics (respectively). Even though the CLR supports both approaches, the before-field-init semantics is the preferred option since it lets the CLR decide when to make the static constructor call (and this can bring huge gains in performance).

In practice, the approach used is defined by the compiler. When the C# compiler sees that you’ve explicitly defined a type constructor, it will always use the precise semantics call. If you’re just using inline initilization (and have no static constructor), then the compiler will use the before-field-init semantics. Notice that this information is maintained in the metadata table of a type (there’s a flag called beforefieldinit which is signaled for the before-field-init semantics).

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

by luisabreu | with no comments
Filed under:
Book review: CLR via C#, 3rd edition
Wed, Jul 14 2010 19:50

Since I’ve started working in my Silverlight book, I’ve been really busy. So busy that I completely forgot to post my review about Jeffrey Richter’s CLR via C# book. Well, to be honest, there’s really not much I can say about it…let me see…basically, I want to say two things:

  • it should be *required* reading for everyone that wants to write code for the .NET platform
  • it’s so good that when someone ask me about it, I  only say this: let’s assume that you only have money to buy a single book for learning .NET. In that case, you should buy this book. Really!

Yes, my friends, this book is really great and this last edition has added some nice chapters on multithreading too, which make it even more compelling. For all that’s worth, I’m giving it 10/10.

by luisabreu | 2 comment(s)
Filed under:
Back to basics: structures instance constructors
Wed, Jul 14 2010 19:45

In the previous post, I’ve talked about some interesting features that explain why reference type’s instance constructors behave the way they do. Today, we’ll keep looking at instance constructors, but we’ll concentrate on structs. Before going on, I’m assuming that you know the difference between value and reference types.

The first thing you should keep in mind is that there’s simply no way for you to prevent the instantiation of a value type. And this happens because you can only add non-parameterless constructors to your customs structs. Don’t even try to add a new parameterless constructor because the C# compiler will stop you immediately when you try to compile your project. Don’t believe me? Ok, try to compile this in C#:

struct Person {
    private Int32 __age;
    public Person(){ 
__age = 10;
} }

[Patiently waiting…]

Ok, we’re ready to keep going…You might be curious on why you can’t add a parameterless constructor to a struct. I was, especially after seeing that the CLR does allow you to add parameterless constructors to value types (ie, you can add a parameterless constructor to a value type, but you’ll need to use another language  - ex.: IL). I must confess that the best explanation I’ve read is in Jeffrey Richter’s fantastic  CLR via C# book (oh damn, I’ve forgot to write a review about it!). Suppose for a minute that we can define parameterless constructors to a value type. What would happen when you execute the following code (ok, never mind the example; concentrate only in the code):

public class Manager {
    private Person _person;
    public Manager() { }
}

If you’re expecting to see the Person’s constructor involved, then you better wait seated in a comfy chair :). In order to improve runtime performance, constructors will only be  called if you call them explicitly  (compare this behavior with the one we have for reference types).  And according to Jeffrey, the team thought that this would confuse developers and opted for not allowing the definition of parameterless constructors in C#.

Now, it’s important to understand that you can still create parameter constructors for you custom structs. They do need to receive parameters and you must ensure that all the private fields are initialized. Take a look at the following snippet:

struct Color {
    private Byte _red;
    private Byte _green;
    private Byte _blue;
    private Byte __alpha;
    public Color(Byte red, Byte blue, Byte green) {
        _red = red;
        _blue = blue;
        _green = green;
    }
}

Anything wrong? Hell, yes! Since verifiable code “insists” that all fields must be written to before they’re read, you must initialize all the private fields from within all the instance constructors that have been added to a custom struct. So, the easiest thing you can do to make the previous code compile is initialize the _alpha field explicitly. Do notice that you must put the initialization code inside your constructor since the instance fields initializers aren’t permitted in value types.

Before ending, there’s still time for showing you an alternate way to initialize all the fields of a value type. Take a look at the following constructor for the Color struct:

public Color(Int32 alpha){
    this = new Color();
    _alpha= alpha;
}

I must confess that the first time I saw this I was really confused :) Ok, so what’s going on here? Glad you asked :) Calling new results in zeroing all the memory required for holding a Color object . You can then set the current instance to that new object. Not very readable, but it might save a few key strokes when you only want to explicitly initialize one of the fields of your struct.

One final note regarding initialization of value type fields in reference types: the CLR ensures that they’re always zeroed during initialization of that reference type. That doesn’t happen when we’re talking about value type fields in other value types. If you’re writing code in a “verifiable” language (ex.: C#), then you’re safe because the compiler will generate code that ensures that those types are zeroed out.

And I guess that’s it. After all, there were lots of things to say about structs instance constructors. Stay tuned for more!

by luisabreu | with no comments
Filed under:
Back to the basics: instance constructors
Mon, Jul 12 2010 15:35

[Update: updated the text that explains why you’d need to make an explicit call to the base class’ constructor. Thanks Damien]

In the last post, I’ve mentioned constructors…but what is a constructor? The first thing you should keep in  mind is that there are several types of constructors and, in this post, we’ll only be talking about instance constructors. So, what’s an instance constructor?

Constructors are special methods which are responsible for initializing an object to a “good” state (curiosity snippet: constructors are represented by .ctor methods in the method definition table of a type). In practice, you create a constructor by adding a method with the same name as the class that does not return anything. Here’s a quick example:

public class Test {
    public Test(){        
    }
}

The previous snippet creates an instance constructor which doesn’t receive any parameters. When you don’t define *any* constructor, the C# compiler will automatically add a parameterless (aka, default) constructor which looks like the one shown in the previous snippet.

When you create a new reference type, the runtime ensures that all the fields of that type are zeroed out before the instance constructor gets called. Since constructors are never inherited, then you cannot use the virtual, new, etc. qualifiers with them.  What you should do is call the base class from within your class’s constructor. The following snippet shows how:

public class Test {
    public Test(): base(){        
    }
}

Once again, if you don’t add the call explicitly, the compiler will try to add one for you. However, if you’ve introduced a non-parameterless constructor in your base and don’t there’s not any parameterless constructor, then you do need to call the base explicitly (the compiler will remind you of that because it won’t compile your code in these cases):

public class Test {
    public Test(String name){
    }
}
public class Derived:Test {
        public Derived(String name): base(name){                
        }
    }
}

Since all types inherit from Object, then you must be probably wondering what happens when the Object’s constructor is called (and it will be called since Object does introduce a default constructor which will be called from within Test’s “customized” constructor). I’m sorry to disappoint you, but the truth is that that constructor simply doesn’t do anything. Yep, that is true…it does nothing, zero, nickles, rien de rien…And the reason for that is really simple: the Object class doesn’t have any state (ie, it defines no fields), so its constructor doesn’t really do anything “visible”.

Even though constructors aren’t inherited, you can still introduce several constructors (overloads) provided they have different signatures. In these cases, you tend to reuse the more specific constructor. Here’s an example of what I mean:

public class Test {
    public Test(String name){
    }
    public Test():this(""){
    }
}

As you can see, the parameterless constructor ends up “redirecting” to the other constructor. Doing this sort of thing is really a good practice because you can centralize all your code in one place.

Before ending this post, there’s still time for talking about initialization. C# allows us to set the initial value of a field in the declaration instruction:

public class Test {
    private Int32 _number = 10;
    public Test(){
    }
}

This is just convenient syntax. During compilation, the compiler will automatically put the initialization for _number in the first line of the default constructor. Do notice that this line is inserted before the call to the base class’ constructor and it will be “replicated” through each of the constructors defined by your class (which might not really be a good thing). In practice, this means that if you have a lot of constructor overloads, you shouldn’t use the field initialization syntax: instead, you should rely on putting the initialization code on a “central” constructor which ends up being called by all the others constructors.

And I guess this covers most of the things you can do with reference type instance constructors. Stay tuned for more.

by luisabreu | 2 comment(s)
Filed under:
Back to the basics: Why is my constructor not being called?
Mon, Jul 12 2010 10:14

When we create a new type and define a constructor, I guess there’s nothing wrong with expecting to see that constructor called whenever a new instance of a type is created. The problem is that there are some cases where that doesn’t happen. For instance, here are two situations where your constructor won’t be called:

  • when you serialize/deserialize an object
  • when you use the MemberwiseClone method

In the past, I’ve already mentioned the serialization gotcha (you can read about it here and here), so in this post, I’ll only be concentrating on the MemberwiseClone method. The MemberwiseClone method is protected and defined by the Object class (which means that it is inherited by all the types). You’ll use this method whenever you want to perform a shallow copy of an instance.

What you must keep in mind is that when you call this method, the constructor of the type that is being duplicated won’t be called. Instead, the method will simply allocate the necessary memory and bit-copy the instance fields to that new allocated memory space.

Since this is a protected method, you’ll only be able to call it from within the text of the class (or from a derived class). This means you’re in control and it shouldn’t really cause the same problems you might get when you use serialization.

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

by luisabreu | 3 comment(s)
Filed under:
Back to the basics: is vs as operator
Fri, Jul 9 2010 14:06

Ok, now that the PT Silverlight book is mostly done (I’m awaiting for feedback form my reviewers – if you’re one of them and you’re reading this post, then stop right now and go back to the manuscript please! :)), I guess it’s time to return to my blog. And I’ll be writing some posts for my basic series, which is a topic that seems to make everyone happy :) - at least, I’ve received several emails about the previous posts, so I assume that this is a subject in which people are interested in.

We’ve all had to do some casting in the past, right? Everyone knows how to write a cast in C#: you just indicate use the ( ) operate, stating the type you want and that’s it. Here’s an example:

var aux = (MyClass)derived;

The previous code will compile, but you might end up getting an exception if derive isn’t a MyClass instance (or derived from it or if you don’t define a conversion operator in your derived’s class). So, how can you check if an object is of a specific type without getting an exception? Enter the is and as operators! The is operator will never throw an exception and it will return a Boolean which indicates if the object is of a specific type:

var isDerived = derived is MyClass;
if( isDerived ){
  //do something but cast before
  //ex.: ((MyClass)derived).CallSomeMethod();
}

You can use this, but I’m guessing that what you’d really love to have is a cast which doesn’t throw an exception when the type you’re casting to isn’t “compatible”. Enter the as operator:

var auxDerived = derived as MyClass;
if( auxDerived != null ){
  //do something
  //no need for casting
  //auxDerived.CallSomeMethod();
}

As you can see, the as operator will try to cast the object into the desired type. When that is possible, the result will automatically point to an instance of that type. When it isn’t, you’ll get null (that’s why you generally test the result of the operator against null before writing the code that accesses the members of the desired type).

Now, before you forget that the is operator exists, take a look at the following snippet:

public struct MyStruct { //more code }
var aux = instance as MyStruct;

Do you see anything wrong? No? Ok, let’s take a look at the docs:

Note that the as operator only performs reference conversions and boxing conversions. The as operator cannot perform other conversions, such as user-defined conversions, which should instead be performed using cast expressions.

In other words, the previous snippet won’t compile because MyStruct is a struck. In fact, if you do read the docs, then you’ll notice that it  says that:

The as operator is like a cast except that it yields null on conversion failure instead of raising an exception. More formally, an expression of the form:
expression as type

is equivalent to:

expression is type ? (type)expression : (type)null

In fact, you’ll be able to program without knowing this (since the compiler will enforce it at compilation time. However, you’ll really be amazed by the number of guys that says that they’re an “expert” in C# and don’t know about this behavior. And did I said that there was one C# “expert” that told me there was no way to “cast” a type into another if there wasn’t a relationship of is-a between them? I guess he didn’t had the time to read the section on converters in the C# spec…And no,I’m not really a C# expert. I’m just a curious guy which finds it interesting to write about this small things which aren’t used/known to many.

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

by luisabreu | 5 comment(s)
Filed under:
Another distraction: I’m now a proud owner of a HTC Desire
Thu, Jun 24 2010 21:51

Yep, my old HTC Touch Pro died and I had to pick a replacement. So, I guess I did the right thing and went with Android and HTC Desire…hum…does this mean I’ll be writing Java? Who knows :)

by luisabreu | 2 comment(s)
Filed under:
More Posts Next page »

Search

This Blog

Tags

Community

Archives

Syndication

Email Notifications

News




  • View Luis Abreu's profile on LinkedIn


    Follow me at Twitter

    My books

    Portuguese LINQ book cover

    Portuguese ASP.NET 3.5 book cover

    Portuguese ASP.NET AJAX book cover

    Portuguese ASP.NET AJAX book cover