January 2007

Monthly Archive

Yield to the iterator

Posted by on 24 Jan 2007 | Tagged as: .NET, C#, Design, Development

I had planned to write a piece about using yield return in c# to allow returning IEnumerable collections in a lazy way, however upon starting up Visual Studio in the news I discovered Bill Wagner’s piece on MSDN entitled ‘Custom Iterators‘ which covers everything I was planning to write about.

On a related note, I happened across a rather old post about the performance of iterating over generic lists – the article compares three ways of iterating the list, with the outcome being (fastest to slowest):

  1. For Statement with cached count
    int iCount = list.Count;
    for (int i = 0; i < iCount; i++)
    //do stuff
  2. ForEach Delegate
    list.ForEach(delegate(ItemType item)
    //do stuff
  3. ForEach Statement
    foreach (ItemType item in list)
    //do stuff

This ordering was pretty much how I expected it to be, but the article has fully example code and some figures to back up the performance difference.

links for 2007-01-19

Posted by on 19 Jan 2007 | Tagged as: Links

CLS Compliance is good for APIs

Posted by on 18 Jan 2007 | Tagged as: .NET, Design, Development

CLS, or the Common Language Specification is a set of rules which make up the most basic features of all .NET languages. Many .NET languages exceed these basic requirements and allow for features above and beyond the basics. For instance, C# allows for case sensitive public members, meaning that object.Property is different to object.property.

When developing .NET libraries for use by other developers it is a very good idea to have your library work in a CLS Compliant way, so that you are enabling all .NET languages to leverage your library. It also proves to be a good idea as many of the CLS Rules reflect good design practices.

In order to indicate that your library is CLS Complaint the whole assembly can be marked as such using the System.CLSCompliantAttribute, so in Visual Studio projects using C# this is often placed in AssemblyInfo.cs and looks something like this:


This attribute tells the C# compiler to check the public aspects of whole assembly against the CLS Specification and will report any breaches of these rules as compile errors.

It is also possible to mark individual types, methods, properties, etc, as CLS Compliant by decorating the definition with the same attribute, like so:

public class MyType{ ....

public string MyFunction() {....

Finally, if you find that you need to exclude something from CLS Compliance, it can be marked as non-compliant by passing a false into the attribute:

//This method can't be CLS compliant as UInt32 is not a CLS type
public UInt32 MyFunction() {....

CLS Compliance may seem like an extra complication to development, but it really is a good idea as it forces you to consider the needs of other developers (in other languages) and does enforce a number of good practices via compile time checks.

Further Information:
Cross-Language Interoperability on MSDN

Next Page »