Skip to main content

What's new in C# 4.0?

C# 4.0 is a version of the C# programming language that was released on April 11, 2010. Microsoft released the 4.0 runtime and development environment Visual Studio 2010.[1]The major focus of C# 4.0 is interoperability with partially or fully dynamically typed languages and frameworks, such as the Dynamic Language Runtime and COMThe following new features were added in C# 4.0.

1. Dynamic member lookup
A new pseudo-type dynamic is introduced into the C# type system. It is treated as System.Object, but in addition, any member access (method call, field, property, or indexer access, or a delegate invocation) or application of an operator on a value of such type is permitted without any type checking, and its resolution is postponed until run-time. This is known as duck typing. For example:
  // Returns the value of Length property or field of any object
  int GetLength(dynamic obj)
  {
    return obj.Length;
  }
 
  GetLength("Hello, world");        // a string has a Length property,
  GetLength(new int[] { 1, 2, 3 }); // and so does an array,
  GetLength(42);                    // but not an integer - an exception will be thrown in GetLength method at run-time
Dynamic method calls are triggered by a value of type dynamic as any implicit or explicit parameter (and not just a receiver). For example:
  void Print(dynamic obj)
  {
     System.Console.WriteLine(obj); // which overload of WriteLine() to call is decided at run-time
  }
 
  Print(123);   // ends up calling WriteLine(int)
  Print("abc"); // ends up calling WriteLine(string)
Dynamic lookup is performed using three distinct mechanisms: COM IDispatch for COM objects, IDynamicMetaObjectProvider DLR interface for objects implementing that interface, and reflection for all other objects. Any C# class can therefore intercept dynamic calls on its instances by implementing IDynamicMetaObjectProvider.
In case of dynamic method and indexer calls, overload resolution happens at run-time according to the actual types of the values passed as arguments, but otherwise according to the usual C# overloading resolution rules. Furthermore, in cases where the receiver in a dynamic call is not itself dynamic, run-time overload resolution will only consider the methods that are exposed on the declared compile-time type of the receiver. For example:
class Base
{
  void Foo(double x);
}
 
class Derived : Base
{
  void Foo(int x);
}
 
dynamic x = 123;
Base b = new Derived();
b.Foo(x); // picks Base.Foo(double) because b is of type Base, and Derived.Foo(int) is not exposed
dynamic b1 = b;
b1.Foo(x); // picks Derived.Foo(int)
Any value returned from a dynamic member access is itself of type dynamic. Values of type dynamic are implicitly convertible both from and to any other type. In the code sample above this permits GetLength function to treat the value returned by a call to Length as an integer without any explicit cast. At run time the actual value will be converted to the requested type.
2. Covariant and contravariant generic type parameters
Generic interfaces and delegates can have their type parameters marked as covariant or contravariant using keywords out and in respectively. These declarations are then respected for type conversions, both implicit and explicit, and both compile time and run time. For example, the existing interface IEnumerable<T> has been redefined as follows:
interface IEnumerable<out T>
{
  IEnumerator<T> GetEnumerator();
}
Therefore, any class that implements IEnumerable<Derived> for some class Derived is also considered to be compatible with IEnumerable<Base> for all classes and interfaces Base that Derived extends, directly or indirectly. In practice, it makes it possible to write code such as:
void PrintAll(IEnumerable<object> objects)
{
  foreach (object o in objects)
  {
    System.Console.WriteLine(o);
  }
}
 
IEnumerable<string> strings = new List<string>();
PrintAll(strings); // IEnumerable<string> is implicitly converted to IEnumerable<object>
For contravariance, the existing interface IComparer<T> has been redefined as follows:
public interface IComparer<in T>
{
    int Compare(T x, T y);
}
Therefore, any class that implements IComparer<Base> for some class Base is also considered to be compatible with IComparer<Derived> for all classes and interfacesDerived that are extended from Base. It makes it possible to write code such as:
IComparer<object> objectComparer = GetComparer();
IComparer<string> stringComparer = objectComparer;
3. Optional ref keyword when using COM
The ref keyword for callers of methods is now optional when calling into methods supplied by COM interfaces. Given a COM method with the signature
void Increment(ref int x);
the invocation can now be written as either
Increment(0); // no need for "ref" or a place holder variable any more
or
int x = 0;
Increment(ref x);
4. Optional parameters and named arguments
C# 4.0 introduces optional parameters with default values as seen in Visual Basic and C++. For example:
void Increment(ref int x, int dx = 1)
{
  x += dx;
}
 
int x = 0;
Increment(ref x);    // dx takes the default value of 1, after the method returns x == 1
Increment(ref x, 2); // dx takes the value 2, after the method returns x == 3
In addition, to complement optional parameters, it is possible explicitly to specify parameter names in method calls, allowing the programmer selectively to pass any subset of optional parameters for a method. The only restriction is that named parameters must be placed after the unnamed parameters. Parameter names can be specified for both optional and required parameters, and can be used to improve readability or arbitrarily to reorder arguments in a call. For example:
Stream OpenFile(string name, FileMode mode = FileMode.Open, FileAccess access = FileAccess.Read) { ... }
 
OpenFile("file.txt"); // use default values for both "mode" and "access" 
OpenFile("file.txt", mode: FileMode.Create); // use default value for "access"
OpenFile("file.txt", access: FileAccess.Read); // use default value for "mode"
OpenFile(name: "file.txt", access: FileAccess.Read, mode: FileMode.Create); // name all parameters for extra readability, 
                                                                            // and use order different from method declaration
Optional parameters make interoperating with COM easier. Previously, C# had to pass in every parameter in the method of the COM component, even those that are optional. For example:
object fileName = "Test.docx";
object missing = System.Reflection.Missing.Value;
 
doc.SaveAs(ref fileName,
    ref missing, ref missing, ref missing,
    ref missing, ref missing, ref missing,
    ref missing, ref missing, ref missing,
    ref missing, ref missing, ref missing,
    ref missing, ref missing, ref missing);
With support for optional parameters, the code can be shortened as
doc.SaveAs(ref fileName);
Which, due to the now optional ref keyword when using COM, can further be shortened as
doc.SaveAs(fileName);
5. Indexed properties
Indexed properties (and default properties) of COM objects are now recognized, but C# objects still do not support them.

Comments

Popular posts from this blog

Accessing File Stored in Windows Azure Blob Storage Using jQuery

Did you know it was possible to access the Windows Azure Blob Storage directly from JavaScript, for example using jQuery? At first, it sounds obvious, since Blobs are after all accessible from a public UR. But in practice, there is a very big hurdle: the Web browser’s Same Origine Policy or SOP, that restricts JavaScript code to accessing resources originating from the same site the script was loaded from. This means that you will never be able to load a Windows Azure Blob using XMLHttpRequest for example! Fortunately, there is a popular workaround called JSONP (“JSON with Padding”). The idea behind this technique is that the script tag is not submitted to the SOP: an HTML page can thus load a JavaScript file from any site. So, if you expose your data in an “executable” form in JavaScript, a page will be able to load this data using a script tag. For example: <script type=”text/javascript” src=”http://www.sandeepknarware.in/exemple.jsonp”> </script> But how can ...

Support for debugging lambda expressions with Visual Studio 2015

Anyone who uses LINQ (or lambdas in general) and the debugger will quickly discover the dreaded message “Expression cannot contain lambda expressions”. Lack of lambda support has been a limitation of the Visual Studio Debugger ever since Lambdas were added to C# and Visual Basic.  With visual studio 2015 Microsoft has added support for debugging lambda expressions. Let’s first look at an example, and then I’ll walk you through current limitations. Example To try this yourself, create a new C# Console app with this code: using System.Diagnostics; using System.Linq; class Program { static void Main() { float[] values = Enumerable.Range(0, 100).Select(i => (float)i / 10).ToArray(); Debugger.Break(); } } Then compile, start debugging, and add “values.Where(v => (int)v == 3).ToArray()” in the Watch window. You’ll be happy to see the same as what the screenshot above shows you. I am using Visual Studio 2015 Preview and it has some limitati...

gcAllowVeryLargeObjects Element

There are numerous new features coming with .NET 4.5 and here, on this blog, you can find several posts about it. But the feature we are goint to talk about today is very exciting, because we were waiting for it more than 10 years. Since .NET 1.0 the memory limit of .NET object is 2GB. This means you cannot for example create array which contains elements with more than 2GB in total. If try to create such array, you will get the OutOfMemoryException. Let’s see an example how to produce OutOfMemoryException. Before that Open Visual Studio 2012, and create C# Console Application, like picture below. First lets create simple struct with two double members like example below: 1 2 3 4 5 6 7 8 9 10 11 12 public struct ComplexNumber {      public double Re;      public double Im;      public ComplexNumber( double re, double im)      {    ...