Explicit Interface Implementation

In C#, you can explicitly implement interface members in your class or struct. C# language specification explains it better than I can:

For purposes of implementing interfaces, a class or struct may declare explicit interface member implementations. An explicit interface member implementation is a method, property, event, or indexer declaration that references a fully qualified interface member name.

Here’s a small example:

public interface IMyInterface
{
    String SayHello();
}

class MyClass : IMyInterface
{
    string IMyInterface.SayHello()
    {
        return "Hello from IMyInterface!";
    }
}

The MyClass explicitly implement the SayHello method from IMyInterface. The interesting thing about explicitly implemented member is that they’re only accessible when accessed trough the interface. From C# language specification again:

It is not possible to access an explicit interface member implementation through its fully qualified name in a method invocation, property access, or indexer access. An explicit interface member implementation can only be accessed through an interface instance, and is in that case referenced simply by its member name.

The below code won’t compile, as the SayHello method is only visible trough the interface:

var o = new MyClass();

Console.WriteLine("MyClass: {0}", o.SayHello());

‘MyClass’ does not contain a definition for ‘SayHello’ and no extension method ‘SayHello’ accepting a first argument of type ‘MyClass’ could be found (are you missing a using directive or an assembly reference?)

Now, let’s add a second method called SayHello with the exact same signature to the class, defined as such:

public string SayHello()
{
    return "Hello from MyClass";
}

This time, the previous code will compile, and will print “Hello from MyClass” in the console.

To access the explicitly implemented method, we have to go trough the interface, calling it as such:

var p = (IMyInterface)o;

Console.WriteLine("IMyInterface: {0}", p.SayHello());

This will print “Hello from IMyInterface” in the console, as expected.

The two primary purpose of explicit interface implementation, as described in the C# language specification, are twofold:

  • Because explicit interface member implementations are not accessible through class or struct instances, they allow interface implementations to be excluded from the public interface of a class or struct. This is particularly useful when a class or struct implements an internal interface that is of no interest to a consumer of that class or struct.
  • Explicit interface member implementations allow disambiguation of interface members with the same signature. Without explicit interface member implementations it would be impossible for a class or struct to have different implementations of interface members with the same signature and return type, as would it be impossible for a class or struct to have any implementation at all of interface members with the same signature but with different return types.

On top of this, a common usage, as described in C# in Depth (2.2.2, page 46), is to palliate the lack of covariant return types (the example is on IClonable interface, see this topic on Stack Overflow).

C# 4.0 and dynamic keyword

With the new dynamic keyword in C# 4.0, a method call on a dynamic object is resolved at runtime. Is is therefore impossible to access the explicitly implemented member on a dynamic object.

dynamic q = new MyClass();
dynamic r = (IMyInterface)q;

Console.WriteLine("MyClass: {0}", q.SayHello());
Console.WriteLine("IMyInterface: {0}", r.SayHello());

The above code will print “Hello from MyClass” twice, as SayHello is called on a object who’s runtime type is MyClass. The only way to access IMyIntergace’s SayHello implementation is to cast q or r to IMyInterface before the call:

Console.WriteLine("IMyInterface: {0}", ((IMyInterface) q).SayHello());

October 11, 2009 | Tags: Tags: , , | Leave a Comment 

Boxing and Unboxing in .NET

I realized that the way boxing and unboxing works in .NET was not something I knew well, so I decided to write some small recap along with code to test boxing/unboxing behaviors.

Some Theory

In .NET, even if value types derive from the uber root object System.Object, they need the special boxing operation to be treaded as object.

A good explanation is given in the C# Language Specification:

A value of a class type can be converted to type object or to an interface type that is implemented by the class simply by treating the reference as another type at compile-time. Likewise, a value of type object or a value of an interface type can be converted back to a class type without changing the reference (but of course a run-time type check is required in this case).

Since structs are not reference types, these operations are implemented differently for struct types. When a value of a struct type is converted to type object or to an interface type that is implemented by the struct, a boxing operation takes place. Likewise, when a value of type object or a value of an interface type is converted back to a struct type, an unboxing operation takes place.

So, when a value type needs to be converted to an object, it is boxed in a reference type. As stated, boxing means that the value type gets copied in the wrapping reference type.

A boxing conversion implies making a copy of the value being boxed. This is different from a conversion of a reference-type to type object, in which the value continues to reference the same instance and simply is regarded as the less derived type object.

The important thing to bear in mind is that boxing and unboxing happens automatically. Everywhere an reference type is expected but a value type is used instead, the value type is automatically boxed.

Another important point is that if the value type has overrides some of the virtual methods inherited from object, invocation of these methods on the value type does not require boxing.

Some Examples

Now, let’s see how it works, and what are the caveats.

A first interesting case is directly taken from Bill Wagner’s “Effective C#”. Consider this code:

Console.WriteLine("A few numbers:{0}, {1}, {2}", 25, 32, 50);

WriteLine takes an array of object references as parameters. This means that the three value types will be boxed before calling the ToString() method on them. To avoid this, ToString() method should explicitely be called on each of these int in order to provide WriteLine with string which are reference types, so there is no boxing.

Console.WriteLine("A few numbers:{0}, {1}, {2}", 25.ToString(), 32.ToString(), 50.ToString());

So, that’s one thing to keep in mind. It’s good for performances reasons, but it doesn’t introduce any bug.

The next step is the copy of the value type in the box itself, meaning that any change to the copied value type in the box will not be reflected in the original copy. Also, when unboxing, the value from the box is copied again.

int i = 5;
var j = (object)i;

i++;

Console.WriteLine("i: {0}", i); //Prints 6
Console.WriteLine("j: {0}", j); //Prints 5

j = (object)i;
var k = (int)j;

k++;

Console.WriteLine("j: {0}", j); //Prints 6
Console.WriteLine("k: {0}", k); //Prints 7

When you think about it, is quite easy and it makes a lot of sense, as in C#, things are copied by value (meaning that when you copy a reference type, you copy the value of the reference, which is what the variable stores).

Last funny thing:

Object.ReferenceEquals(5, 5); //Returns false

It’s easy to understand. The two value types (5 and 5) are each boxed in a separate reference type, which don’t have the same reference.

A small warning tough, everything I write here is from quite trusted sources, but it may happen that I misunderstood something, so ask a real expert if you want to be sure…

September 5, 2009 | Tags: Tags: , | Leave a Comment 

Constant in Eclipse and in Visual Studio

Java naming conventions states that constants, declared as static and final, must be named all uppercase. Eclipse will automatically turn these guys in blue and italic. Here is an example of what it will look like in Eclipse:

public class Sandbox {
    public static final String CONSTANT_VALUE = "Hello World!";

    public static void main(String[] args) {
        System.out.println(CONSTANT_VALUE);
    }
}

That’s pretty neat. You cannot miss a constant, even if it is not fully qualified (it has to be if it is from another class, of course).

According to Microsoft’s naming conventions, constants in C# (that use the const keyword, being compile time constants) have to be named using Pascal Case. Visual Studio doesn’t color it any special way, meaning that if it is not qualified, you cannot know if it is a constant, a propertie, a variable…

Here is what it looks like:

class Sandbox
{
    const String ConstantValue = "Hello World!");

    static void Main(string[] args)
    {
        Console.WriteLine(ConstantValue);
    }
}

I find this a bit disturbing, as constant should always be easy to recognize. Well, at least that what I think. I was not able to find any option in Visual Studio to change this. A good start is to always fully qualify constants, in this case using Sandbox.ConstantValue (same advice goes for this keyword, I always use it, even when unnecessary).

You can find some more details on this subject here on stackoverflow.

August 13, 2009 | Tags: Tags: , , , , , , | Leave a Comment 

Java Inheritance VS C# Inheritance

This topic is very basic, but I felt like writing something on simple subjects that may be misunderstood. It is also a good excuse to go in language specifications and read all the details that most of the people don’t like to read… As I’m working in Java now, I quite like to compare the two languages to see where are the differences and make sure I don’t do any silly mistake.

So, when it comes to inheritance, there is a big difference between Java and C#.

Java Inheritance

In a Java subclass, you can override any method of the superclass. The method that is to be called is always determined at run time. So for example, if you write code like this:

public class Parent {
    public String sayHello() {
        return "Hello from Parent";
    }
}

public class Child extends Parent {
    public String sayHello() {
        return "Hello from Child";
    }
}

If you create a new instance of the Child class, when you call the sayHello() method, it is always the Child one that will be called, no matter what the declaration class is. So, you can teat an instance of Child as an instance of Parent, but the methods called will be the ones from Child (if they are overriden, of course).

Code like this:

Parent o = new Child();
System.out.println(o.sayHello());

will output this:

Hello from Child

C# Inheritance

In C#, things are a bit different. C# language needs to be told which method can be overriden (declared as virtual), and which method overrides (declared as override). So to have the same behavior as Java, C# code has to look like this:

class Parent
{
    public virtual String SayHello()
    {
        return "Hello from Parent";
    }
}

class Child : Parent
{
    public override String SayHello()
    {
        return "Hello from Child";
    }
}

If the virtual and override are omitted (or just the override, actually), then it is the Parent’s method that is executed when the Child object is declared as Parent.

In C# language specification, there is a clear explanation on how is behaves:

In a virtual method invocation, the run-time type of the instance for which that invocation takes place determines the actual method implementation to invoke. In a non-virtual method invocation, the compile-time type of the instance is the determining factor.

Summary

To sum it up, in Java the method called will be determined by the instantiation class, while in C# it will depend on how the class and the calling code is written. C# gives you much more flexibility, but it is more complicated and the capacity for a class to override a method is determined by its parent class. With Java, you loose the ability to call the parent’s method, but is that very useful? On the other hand, C# ensures that if you don’t want a method to be overriden, it won’t be.

Oh and we forgot to talk about the new keyword in C#. I never came across code that used it, but a nice description is given here.

June 19, 2009 | Tags: Tags: , , | Leave a Comment 

Boolean Logical Operators and Boolean Conditional Logical Operators

I’m often amazed that most programmer don’t know that in C# and in Java you can use the simple & and | as logical operators. It seems than most people don’t event know that they exist!

But what’s the difference between these simple and double logical operators?

Back To Basics

Let’s see in the C# language specifications:

The result of x & y is true if both x and y are true. Otherwise, the result is false.

The result of x | y is true if either x or y is true. Otherwise, the result is false.

Now let’s have a look in Java language specifications:

For &, the result value is true if both operand values are true; otherwise, the result is false.

For |, the result value is false if both operand values are false; otherwise, the result is true.

It’s pretty clear, it does what most of the people would expect them to do, and and or operations.

But, then, what are those && and || that most developers use everywhere, wasting bytes like there’s now tomorrow?

Again, specifications are there to give full explanations.

In C#:

The && and || operators are conditional versions of the & and | operators:

  • The operation x && y corresponds to the operation x & y, except that y is evaluated only if x is true.
  • The operation x || y corresponds to the operation x | y, except that y is evaluated only if x is false.

And in Java:

The && operator is like & (§15.22.2), but evaluates its right-hand operand only if the value of its left-hand operand is true.

The || operator is like | (§15.22.2), but evaluates its right-hand operand only if the value of its left-hand operand is false.

Tadaaaam! Now it makes perfect sense, doesn’t it? These operators that most of the people use everywhere are smart and only evaluate the right-side if it is of any use (if left-hand side is true for and, if left-hand side is false for or).

So, let’s give a small example of how this can be useful. Let’s pretend you have an object that has a member that can be null. With these operators, you can test it without any fear of the dreaded NullReferenceException or NullPointerException. Here is a small piece of C# code that shows the point:

var p = new Parent { Name = "Father" };
p.Childs = new Person[] { new Person() { Name = "Son" } };

if (p.Childs != null && p.Childs.ElementAt(0).Name != null)
{
    Console.WriteLine("First Child's name: {0}",
        p.Childs.ElementAt(0).Name);
}

If Child collection was left null, this code would still work even though p.Childs.ElementAt(0) would normally throw an ArgumentNullException. As p.Childs != null returns false, the right-hand operand is not evaluated so no exception is thrown.

Now, as you may say “Well in this case, why does it matter? Let’s use && and || everywhere, so we make no mistake!”. Technically, it is true. However, as one of my University teacher said:

Les gens qui utilisent les opérateurs conditionnels booléens partout sont des gens qui ne savent pas ce qu’ils font.

Translation: “Peoples who use conditional logical operators everywhere are peoples that don’t know what they’re doing”.

Of course, his point was that you should understand the code you are writing and that you should know when which part of an expression can be evaluated. I have no clue if there is a performance gain when using non conditional operators, nor if there is any compiler optimization of any kind.

The Third Operator

There is also a third operator in both languages: ^.

In C#:

The result of x ^ y is true if x is true and y is false, or x is false and y is true. Otherwise, the result is false. When the operands are of type bool, the ^ operator computes the same result as the != operator.

In Java:

For ^, the result value is true if the operand values are different; otherwise, the result is false.

I’v never seen this operator used. As pointed in C# specification, this operator has the same result as the != operator.

And, of course, it doesn’t make any sense to have a ^^ operator, as both operand have to be evaluated in all the cases…

June 4, 2009 | Tags: Tags: , , , | 1 Comment 

← Previous Page — Next Page →