A union is a data structure that stores several different types of data at the same single location in memory. Although this might sound like madness in a garbage collected world many older binary data formats still heavily rely on this. A possible use is if you want to modify an IPv4 address. An IPv4 address is 4 bytes, or an unsigned C# int. You might want to manipulate the IP address as a single value, or by splitting it into four separate bytes.

C# does not have a union keyword like C or C++ but it is still possible to create the same result by using the StructLayout(LayoutKind.Explicit) and FieldOffset attributes which are part of System.Runtime.InteropServices (which as the name suggests supplies code for working with unmanaged code).

C# allows for three distinct ways of layout data structures in memory: Auto, Explicit, and Sequential. The default is “Auto”, but for this to work we need “Explicit”.

The FieldOffset sets the physical position of fields within the representation of a class or structure. But what it also allow you to do is to set the same position twice. In the below example we will let the unsigned int for the IP address start at the same spot as the most significant byte.

using System;
using System.Runtime.InteropServices;

namespace ipv4
{

    [StructLayout(LayoutKind.Explicit)]
    struct IPv4Address
    {
        [FieldOffset(0)]
        public uint Address;
        [FieldOffset(0)]
        public byte b3;
        [FieldOffset(1)]
        public byte b2;
        [FieldOffset(2)]
        public byte b1;
        [FieldOffset(3)]
        public byte b0;
    }

    class MainClass
    {
        public static void Main(string[] args)
        {
            IPv4Address myAddress;

            // Assign localhost to the IPv4 address
            myAddress.Address = 0; // Avoid CS0170: Unassigned Field error
            myAddress.b0 = 127;
            myAddress.b1 = 0;
            myAddress.b2 = 0;
            myAddress.b3 = 1;

            Console.WriteLine("The address in hexadecimal: {0:x}",myAddress.Address);
        }
    }
}

Image credit: Jeff Belmonte

This is a post from Martijn's C# Coding Blog.

To understand why you would want to do this, a little history: One of the good things about C is that it works on every imaginable platform, the bad thing was of course that it works on every imaginable platform. There was always a little tweaking required to get your code to compile. Your program might have needed to compile on Amiga, DOS , OS/2, Windows or Linux. The invention of the preprocessor made this much easier. As a separate step prior to compilation it combs through the source code and modifies it according to the pre-processing instructions found in the source code. The C compiler never gets to see the things that don’t apply to it.

In C# there is no separate preprocessor step instead the compiler itself skims through the code as it reads it. Fortunately it is also nowhere near as complex as the C pre-processor.

Contents

• The #define and #undef directives
• Unlike C and C++ there are no macros in C#
• Conditional Compilation with #if / #else / #endif
• Avoid the clutter – use conditional attributes instead
• Using #error and #warning during compilation
• Generated code builds and error reporting with #line
• Region Directives

The #define and #undef directives

The basis of the C# preprocessor directives are #define and #undef. They allow you to create and destroy symbols used by the preprocessing step.

#define TESTVERSION
#undef DEBUG

A common use is for a programmer to turn on and off the inclusion of debugging code. When you are coding and debugging this allow you to test your code but this code shouldn’t be present in the production version of your software.

It is possible to set symbols using /define on the compilers command line allowing you to build scripts that produce different versions of your code. For example a “full version” and a limited “demo” version.

C# does not have any pre-defined symbols, except for maybe DEBUG

If you are used to your C/C++ compiler setting large numbers of symbols so that you could identify the compiler and version you will puzzled to discover the C# doesn’t have any. So you cannot check for the .NET version from a pre-defined symbol and branch your code based on that. (The closest that you can do is to check for the execution environment at runtime, for example if you want to know if you a running under mono.)

If you are compiling your code in the Visual C# / MonoDevelop environment there will be one symbol defined you can use: DEBUG. This is set in the project options and if you are building your code you can select if you want to build the Debug or Release version.

Unlike C and C++ there are no macros in C#

The following is not going to fly on C#. Macro’s are commonly used to expand expressions while compiling C code. A common problem is that C doesn’t have a boolean type. So the first thing most programmers do when starting a new project is to define their own as shown in the next little C code snippet:

#include <stdio.h>

#define BOOL  int
#define TRUE   1
#define FALSE  0
#define IS_TRUE(x) (x == TRUE)

void main()
{
        if (IS_TRUE(TRUE))
        {
          printf("It is TRUE!");
        }
}

When the C preprocessor comes across this it would replace “BOOL” with int, FALSE with 0 and TRUE with 1. The compiler never saw the BOOL, or the TRUE or FALSE. But lets not hang around here — as said, this is not supported by C#

Conditional Compilation with #if / #else / #endif

Of course, if you can define symbols you need to be able to test for them as well. The #if / #else / #endif directives do just that. If you are building the debug version of your code, you can check for the DEBUG symbol:

#if DEBUG
Console.WriteLine(”Things are not going so well!”);
#endif

If you are not building the Debug version of your code — the above line is never seen by the compiler, and thus is not included in the assembly. All #if statements need to be closed by an #endif, and of course you can also use an #else statement:

#if DEBUG
Console.WriteLine(”Things are not going so well, some more debugging is needed!”);
#else
Console.WriteLine(”Fatal Error: Please call free support (0800) 123 123″);
#endif

The #eif directive is a short form for “#else #if #endif”, it works the same but you can save some space as you do not need to end with another #endif. If your project has a more complicated release schedule with alpha, beta and production releases you could try this:

#if (!RELEASE)
Console.WriteLine(”This is not a release version”);
#if (BETA)
Console.WriteLine(”Beta, for limited release only”);
#eif (ALPHA)
Console.WriteLine(”Alpha, for internal testing only”);
#endif
#else
Console.WriteLine(”Welcome to Widgets 1.0″);
#endif

As can be seen you can apply several operators to the symbols: ! (not),== (equality), != (inequality), && (and) and || (or).

Avoid the clutter – use conditional attributes instead

Even a small program has many potential spots where you might like to introduce a debug statement or a log function. If you have to put each of them into a seperate #if DEBUG / #endif block they will start to take up a lot of space in your code. C# has its own slightly more elegant solution to this problem: conditional attributes. They are included in the System.Diagnostics namespace.

In the following program the “LogLine” function will only ever run if the “DEBUG” symbol has been set.

using System;
using System.Diagnostics;

namespace MyNameSpace
{
    class MainClass
    {
        [ Conditional("DEBUG") ]
        public static void LogLine(string msg,string detail)
        {
            Console.WriteLine("Log: {0} = {1}",msg,detail);
        }

        public static void Main(string[] args)
        {
            int Total = 0;
            for(int Lp = 1; Lp < 10; Lp++)
            {
                LogLine("Total",Total.ToString());
                Total = Total + Lp;
            }
        }
    }
}

You can also define combinations chained together with OR to decide if the code is enabled:

[ Conditional("ALPHA"),Conditional("BETA") ]
public static void LogLine(string msg,string detail)

Conditionals work differently from the #if/#endif directives that in the above example the “LogLine” code will still be included in the assembly. It will never get called however. The compiler will ensure that the LogLine method isn’t called. In fact if you use a dissasembler (like monodis) the code for Main will look like this:

        public static void Main(string[] args)
        {
            int Total = 0;
            for(int Lp = 1; Lp < 10; Lp++)
                Total = Total + Lp;
        }

Using #error and #warning during compilation

C# provides the #error and #warning directives to output messages during compilation. As you can expect, if the compiler encounters an #error it will report the problem and stop compiling. The #warning directive just causes a log entry to be displayed in the build output.

#if !DEBUG
#warning This code is NOT production ready
#endif

Generated code builds and error reporting with #line

In regular coding there are not many uses for #line. This directive is mostly useful when you build a code generator that turns one source file into another. Microsoft uses this for example for ASP.NET. Normally if something breaks during such an intermediate step, the compiler would report the error as being in the intermediate file.

The #line directive can force the compiler to report the error as coming from a different line numer, or even a completely different source file.

        public static void Main(string[] args)
        {

#line 250
#if DEBUG
#error This code is NOT production ready
#endif

Even though in my original test code the warning was given at line 19 in the source file, the #line directive forces the compiler to report 250 instead.

Region Directives

The Visual Studio suite, and the newer MonoDevelop versions allow for outlining of code blocks. You click the little (+) next to the code and it expands the class or method. The #region and #endregion directives allow you to define your own outlined blocks.

#region myregion
        public static void Main(string[] args)
        {
            int Total = 0;
            for(int Lp = 1; Lp < 10; Lp++)
{
                LogLine("Total",Total.ToString());
                Total = Total + Lp;
            }
        }
#endregion

This is a post from Martijn's C# Coding Blog.

To understand how LINQ works, and to realize that its more than just syntactic sugar added to C# we first need to review a couple of basic concepts that when combined lead to LINQ.

Simple definitions, simplified

In typical C# you will always carefully spell out your definitions:

string MyString = “Hello World”;

From the right side of the declaration it is obvious that only one type (string) will ever match this definition. So instead of us doing the work, why not let the compiler figure this out?

var MyString = “Hello World”;

The above definition will also create a string variable named “MyString”. It is important to note that C# is still strongly typed — unlike scripted languages such as Visual Basic (or PHP) once you have assigned the variable type it sticks. The following will not work:

var MyString2 = “Hello World”;
MyString2 = 123; // Nice try, but no banana

The compiler will throw an implicit conversion error as 123 cannot be assigned to a string.

The above was an impressive (if somewhat pointless) example of what an anonymous type is. For simple types such as strings, integers etc anonymous types offer little benefits. It is even possible to argue that it reduces your code readability.

Using anonymous types for creating arrays

We are not limited to simple types – the following example show how we can create an anonymous array of integers:

int[] myIntArray = new int[] { 1 , 2 , 3 , 4 , 5 , 6 };
var myIntArrayVar = new [] { 1 , 2 , 3 , 4 , 5 , 6 };

The above two examples are equivalent. You still need to specify that you want to create an array using new. You are however limited by how flexible the compiler is. A mixed array is a little too much and we need to force it down to an object array:

var myMixedArray = new [] { 1, “two” , 3 , “four” , 5 }; // this does NOT work
object[] myMixedArray = new object[] { 1, “two” , 3 , “four” , 5 }; // this is OK

Saving time and code with anonymous types

One very powerful feature of anonymous types it that they can save you a lot of work. Instead of having to type out everything explicitly, you can have the compiler infer the definition of a complete class:

using System;
class MainClass
{
        public static void Main(string[] args)
        {
            var Person = new { Name = "Michael", Age = 23 };
            Console.WriteLine("Name: {0} Age: {1}",Person.Name,Person.Age);
        }
}

The compiler creates an anonymous definition of a class and assigns to it Name and Age as public fields. We can combine anonymous classes and anonymous arrays to create an Employee data structure. Note that we use a “Var” in the ForEach loop. Because we are combining anonymous types it is impossible to determine the correct type to loop over each element in the array. Thankfully we can ask the compiler to fill in the correct iterator type for us:

    using System;
    class MainClass
    {
        public static void Main(string[] args)
        {
            var Person1 = new { Name = "Michael", Age = 23 };
            var Person2 = new { Name = "Sandra", Age = 33 };
            var Employees = new [] { Person1, Person2 };

            foreach (var P in Employees)
                Console.WriteLine("Name: {0} Age: {1}",P.Name,P.Age);

        }
    }

As Employees is an array we can use an iterator to step through it as shown above, but we can just as easily use a for loop:

    using System;
    class MainClass
    {
        public static void Main(string[] args)
        {
            var Person1 = new { Name = "Michael", Age = 23 };
            var Person2 = new { Name = "Sandra", Age = 33 };
            var Employees = new [] { Person1, Person2 };

            for(int Lp = 0; Lp < Employees.Length; Lp++)
              Console.WriteLine("Name: {0} Age: {1}",Employees[Lp].Name,Employees[Lp].Age);
        }
    }

Lambda expressions and anonymous methods

Lambda expressions are an extension of Anonymous Methods which were introduced in C# 2.0 Lambda expressions add a lot of power to C#, but they can be hard to understand. They are however great for small filters than can be passed on to functions as variables as we will see in the following example:

Func<int,bool> mySeniorStaffFilter = a => a > 35;
Console.WriteLine(”36 is senior? {0}”,mySeniorStaffFilter(36));

The above function can be defined anywhere inside your code. It takes a single integer as a parameter and returns a boolean. The integer is defined as “a”, and the function checks whether a is larger than 35.

Using the “old” anonymous methods we could have written the above as:

Func<int,bool> mySeniorStaffFilter = delegate(int a) { return a > 35; };

The Lambda expression syntax is the same, but shorter and this make them slightly easier to understand.

Combining Lambda expressions with Queries

If you have used Intellisense in Visual Studio or the greatly improved object browser in MonoDevelop 2.0 you will discover that with C# 3.0 arrays have a much larger set of methods associated with them. One of these methods is “Where”. It takes a filter as an argument ; and then simply applies each member of the array to the filter. If the filter returns “true” the value is yielded and returned in a sub-set.

In plain language: If you have an array of employees you can pass mySeniorStaffFilter function to the Where method. It checks every staff member to see if their age is over 35 and then returns an array containing only those members of staff.

var SeniorStaff = Employees.Where(s => s.Age > 35);

The following code example shows how this works:

   using System;
   using System.Linq;

    class MainClass
    {
        public static void Main(string[] args)
        {
            var Employees = new [] { new { Name = "Michael", Age = 23 },
                                     new { Name = "Anton", Age = 43 },
                                     new { Name = "Nadia", Age = 36 },
                                     new { Name = "Lydia", Age = 34 } };

            var SeniorStaff = Employees.Where(s => s.Age > 35);          

            foreach(var Member in SeniorStaff)
             Console.WriteLine("Name: {0} Age: {1}",Member.Name,Member.Age);

        }
    }

From the above you can see that the compiler needs to infers,create and apply several anonymous types to create a working code sample. We thankfully can use “var” to specify our SeniorStaff sub-set. Behind the scenes the compiler has created an anonymous IEnumberable for SeniorStaff that contains our Employee records with anonymous staff members. And for the Where method it applied an anonymous delegate to create the correct filter.

And this leads us to the first real “LINQ” statement.

var SeniorStaff = from S in Employees where S.Age > 35 select S;

When you take away the syntactic sugar the C# compiler will build from this the same (or very similar) “Employees.Where(s => s.Age > 35)” statement. Using the same anonymous methods, variables and functions as we used earlier.

This took a lot of getting to. It is however important to understand that LINQ is implemented in C# through basic, strongly typed variables and methods.

To keep the complexity of our C# code down the “var” keyword was added allowing the programmer to focus on coding the logic of the program instead of having to write long hand type definitions for each variable.

Q. Is var typesafe?

There’s no concern about type-safety, as the variable created is not dynamic. It’s just compiler magic and any type unsafe calls you make will get caught.

Q. Is there a performance penalty for using “var” ?

The var keyword only tells the compiler to infer the type from the assignment, there’s no runtime difference, so no, there’s no penalty performance wise.

Q. On using anonymous definitions in large projects

Anonymous types cannot be shared across assembly boundaries. The compiler ensures that there is at most one anonymous type for a given sequence of property name/type pairs within each assembly. To pass structures between assemblies you will need to properly define them.

References

1. http://msdn.microsoft.com/en-us/library/bb308959.aspx

This is a post from Martijn's C# Coding Blog.

    using System;
    using System.Linq;

    class MainClass
    {

        public static void Main(string[] args)
        {
            String[] world = { "Hello World", "Hello Mars" , "Hello Venus" };

            var rightOne = from s in world where s.EndsWith("World") select s;

            foreach(string planet in rightOne)
                Console.WriteLine("{0}",planet);
        }
    }

The first time I tried compiling it, MonoDevelop gave me the following error:

An implementation of `Where’ query expression pattern could not be found. Are you missing `System.Linq’ using directive or `System.Core.dll’ assembly reference?(CS1935)]

You can solve this by ensuring that you have added “System.Core” as a reference to your solution/project. You can do this by right clicking “References” in the “Solution Panel” and selecting “Edit References”.

This is a post from Martijn's C# Coding Blog.