Priyang Patel’s Weblog


?? Operator (null-coalescing operator)

Posted in C# 3.0 by priyangpatel on September 10, 2009
Tags:

?? is used to define a default value for a nullable value types as well as reference types. It returns the left-hand operand if it is not null; otherwise it returns the right operand.

A nullable type can contain a value, or it can be undefined. The ?? operator defines the default value to be returned when a nullable type is assigned to a non-nullable type. If you try to assign a nullable value type to a non-nullable value type without using the ?? operator, you will generate a compile-time error. If you use a cast, and the nullable value type is currently undefined, an InvalidOperationException exception will be thrown.

Example

Example

Advertisements

C# 3.0 New language features

Posted in C# 3.0,Visual Studio 2008 by priyangpatel on March 27, 2008

Automatic Properties

If you are a C# developer today, you are probably quite used to writing classes with basic properties like the code-snippet below:

public class Person {

private string _firstName;
private string
_lastName;
private int
_age;

public string FirstName {

get {
return _firstName;
}
set {
_firstName
= value;
}
}

public string LastName {

get {
return _lastName;
}
set {
_lastName
= value;
}
}

public int Age {

get {
return _age;
}
set {
_age
= value;
}
}
}

Note about that we aren’t actually adding any logic in the getters/setters of our properties – instead we just get/set the value directly to a field. This begs the question – then why not just use fields instead of properties? Well – there are a lot of downsides to exposing public fields. Two of the big problems are: 1) you can’t easily databind against fields, and 2) if you expose public fields from your classes you can’t later change them to properties (for example: to add validation logic to the setters) without recompiling any assemblies compiled against the old class.

The new C# compiler that ships in “Orcas” provides an elegant way to make your code more concise while still retaining the flexibility of properties using a new language feature called “automatic properties”. Automatic properties allow you to avoid having to manually declare a private field and write the get/set logic — instead the compiler can automate creating the private field and the default get/set operations for you.

For example, using automatic properties I can now re-write the code above to just be:

public class Person {

public string FirstName {
get; set;
}

public string LastName {
get; set;
}

public int Age {
get; set;
}
}

Or If I want to be really terse, I can collapse the whitespace even further like so:

public class Person {
public string FirstName { get; set; }
public string LastName { get; set; }
public int Age { get; set; }
}

When the C# “Orcas” compiler encounters an empty get/set property implementation like above, it will now automatically generate a private field for you within your class, and implement a public getter and setter property implementation to it. The benefit of this is that from a type-contract perspective, the class looks exactly like it did with our first (more verbose) implementation above. This means that — unlike public fields — I can in the future add validation logic within my property setter implementation without having to change any external component that references my class.

Object Initializers

Types within the .NET Framework rely heavily on the use of properties. When instantiating and using new classes, it is very common to write code like below:

Person person = new Person();
person.FirstName = “Scott”;
person.LastName = “Guthrie”;
person.Age = 32;

Have you ever wanted to make this more concise (and maybe fit on one line)? With the C# and VB “Orcas” compilers you can now take advantage of a great “syntactic sugar” language feature called “object Initializers” that allows you to-do this and re-write the above code like so:

Person person = new Person { FirstName=“Scott”, LastName=“Guthrie”, Age=32 };

The compiler will then automatically generate the appropriate property setter code that preserves the same semantic meaning as the previous (more verbose) code sample above.

In addition to setting simple property values when initializing a type, the object initializer feature allows us to optionally set more complex nested property types. For example, assume each Person type we defined above also has a property called “Address” of type “Address”. We could then write the below code to create a new “Person” object and set its properties like so:


Person person = new Person {
FirstName
= “Scott”,
LastName
= “Guthrie”
Age = 32,
Address
= new Address {
Street
= “One Microsoft Way”,
City
= “Redmond”,
State
= “WA”,
Zip
= 98052
}
}
;

Collection Initializers

Object Initializers are great, and make it much easier to concisely add objects to collections. For example, if I wanted to add three people to a generics-based List collection of type “Person”, I could write the below code:

List people = new List();

people.Add( new Person { FirstName = “Scott”, LastName = “Guthrie”, Age = 32 } );
people.Add( new Person { FirstName = “Bill”, LastName = “Gates”, Age = 50 } );
people.Add( new Person { FirstName = “Susanne”, LastName = “Guthrie”, Age = 32 } );

Using the new Object Initializer feature alone saved 12 extra lines of code with this sample versus what I’d need to type with the C# 2.0 compiler.

The C# and VB “Orcas” compilers allow us to go even further, though, and also now support “collection initializers” that allow us to avoid having multiple Add statements, and save even further keystrokes:

List people = new List {
new Person { FirstName = “Scott”, LastName = “Guthrie”, Age = 32 },
new Person { FirstName = “Bill”, LastName = “Gates”, Age = 50 },
new Person { FirstName = “Susanne”, LastName = “Guthrie”, Age = 32 }
}
;

When the compiler encounters the above syntax, it will automatically generate the collection insert code like the previous sample for us.