How Optional Arguments in C# 4 Actually Work
In my last post, I discussed one of my favorite new features in C# – Optional and Named Arguments. Although they are very easy to use, and quite intuitive, I have seen few discussions which explain how they actually work. Understanding how they are implemented helps in understanding the repercussions of using these features in development.
Optional and Named Arguments in C# 4
After focusing on some of the .NET framework enhancements, I thought I’d turn my attention to two of my most anticipated new features coming with C# 4 – Optional and Named Arguments. These two features provide benefits I haven’t seen mentioned in most of the announcements…
Strings get even better with .NET 4
Handling text has always been the bane of my programming career. Starting off as a C developer forever tainted me when it comes to processing text; it’s difficult for me to not cringe every time I think of having to do text parsing. String manipulation in .NET was a pleasant surprise for me – when I started with C# I found I suddenly lost my urge to wince every time I had to deal with text input, and no longer was I itching to jump over to a loosely typed language just for handling string manipulation. The System.String class in .NET provided most of the ease of use I missed in C (and even C++).
However, even in .NET, there have been little annoyances when dealing with the String class. Version 4 of the .NET framework, again, adds some functionality to simplify day to day programming tasks. It’s really nice to see that the base class library team is giving some attention to the core, very common classes. Here is a summary of the changes to the String class, and why they help.
Long overdue Enum goodness in .NET 4
The more I investigate the changes in Version 4 of the .NET framework, the more I find little tweaks that just reduce the pain of day to day programming. For example, the System.Enum class is getting some extra methods that finally make day to day programming a bit simpler.
Lazy initialization in .NET 4 – Lazy<T>
A very common pattern in programming is the Lazy Initialization Pattern. Version 4 of the .NET Framework makes using this pattern very, very easy.
WPF – Common Dependency Property Exception
Unlike standard .NET properties, implementing a DependencyProperty requires a bit more code, and has the potential to cause nasty errors to creep up at runtime, without any compile time warnings. Here’s one easy, common mistake, as well as an explanation of why it occurs…
Using a Behavior to Aggregate Values in a Master-Detail view in M-V-VM
It is very difficult to handle situations in a master-detail view, where the master side displays a value derived from aggregating the detail collection. The Model-View-ViewModel pattern makes this even more challenging, since most means of handling this require changing your model, or using extensive code behind.
Using Behaviors to Allow the ViewModel to Manage View Lifetime in M-V-VM
One common issue people face in the Model-View-ViewModel pattern is how to cleanly deal with the lifetime of the View from within the ViewModel. Keeping all of the logic in the ViewModel for preventing the View from closing can be a daunting task, especially at first.
About Big-O Notation – The good, the bad, and the confusing
Often, prior to using a specific algorithm, it helps to understand information about how the algorithm scales. In order to document this, computer science has borrowed a notation from mathematics called Big-O notation.
Understanding Big-O notation is critical in making good decisions about algorithms or libraries used to implement routines. However, there is often a lot of misunderstanding about what it means, and I frequently see this used as justifications for poor decisions.
Preventing Event-based Memory Leaks – WeakEventManager
Events are a common source of memory leaks in .NET applications.
When an object (the receiver) subscribes to an event on another object (the sender), the sender holds a reference to the receiving object. This is because the standard event mechanism in .NET works based off delegates, which contain two member fields – _target and _methodPtr. In this case, _target acts as a strong reference to the receiver. Later, if the receiver is no longer needed, it must unsubscribe from the event, or the event itself will keep the receiving object rooted, preventing the garbage collector from reclaiming its memory. This can lead to large memory leaks – especially if the receiver itself holds large amounts of memory.
Normally, this isn’t a problem; its easy to just unsubscribe from the event, which prevents the above from occurring. However, there are times when the useful lifetime of a receiver of an event isn’t tied to the sender at all, which can make unsubscribing very difficult. WPF introduced a new class and pattern for handing this situation: the WeakEvent Pattern.
