http://csharpfeeds.com CSharpFeeds - All your C# feeds in one place. (Note that this kind of breakage was mentioned a long time ago in Eric Lippert's blog, although not in this exact form.) Whenever a conversion becomes available where it wasn't before, overload resolution can change its behaviour. From C# 1 to C# 2 this happened due to delegate variance with method group conversions - now the same thing is true for generic variance for interfaces. What does the following code print? using System; using System.Collections.Generic; class B http://feedproxy.google.com/~r/JonSkeetCodingBlog/~3/a66dKV5dTTc/evil-code-of-the-day-variance-and-overloading.aspx skeet Mon, 13 Jul 2009 16:10:00 GMT A long and detailed discussion of how exactly we implement iterator blocks would take me quite a while, and would duplicate work that has been done well by others already. I encourage you to start with Raymond’s series, which is a pretty gentle introduction: part 1, part 2, part 3. If you want a more detailed look at how this particular sausage is made, Jon’s article is quite in-depth. To make a long story short, we implement iterators by: Spitting a class that implements the relevant interfac http://blogs.msdn.com/ericlippert/archive/2009/07/13/iterator-blocks-part-two-why-no-ref-or-out-parameters.aspx Eric Lippert Mon, 13 Jul 2009 13:35:00 GMT In the previous post, we’ve started looking at interlocked operations. As we’ve seen, interlocked operations are great at what they do but they won’t be usable in all scenarios (ie, don’t think that they’ll solve all your locks problems). To show how things might go awry when using interlocks, I’ll reuse a great example written by Raymond Chen a few years ago (I’m updating it to C#): class Program { private static Object _lock = new Object(); public static Int64 InterlockedMultiply( http://feedproxy.google.com/~r/Laneten/~3/ys-wRba6XcQ/multithreading-when-interlocked-operations-aren-t-enough.aspx luisabreu Thu, 02 Jul 2009 14:45:30 GMT As we’ve seen in the previous post, most processors give us important insurances regarding memory loads and stores. However, even though those insurances are important and can be used in several scenarios, the truth is that they aren’t enough for all real world tasks. Fortunately, most processors also offer a group of interlocked operations which enable atomic compare and swap scenarios. These operations rely on hardware and interprocess synchronization. Notice that these operations aren’t as s http://feedproxy.google.com/~r/Laneten/~3/kl_AGtVTFoE/multithreading-introducing-the-interlocked-operations.aspx luisabreu Thu, 02 Jul 2009 11:58:04 GMT [UPDATES below]  A while back I described a kind of variance that we’ve supported since C# 2.0. When assigning a method group to a delegate type, such that both the selected method and the delegate target agree that their return type is a reference type, then the conversion is allowed to be covariant. That is, you can say: Giraffe GetGiraffe() { … }…Func<Animal> f = GetGiraffe; This works logically because anyone who calls f must be able to handle any animal that comes back. The actu http://blogs.msdn.com/ericlippert/archive/2009/06/29/the-void-is-invariant.aspx Eric Lippert Mon, 29 Jun 2009 14:30:00 GMT Until now, we’ve been busy talking a look at several interesting topics associated with multithreading programming. As we’ve seen, one of the most problematic areas in multithreaded programs is sharing state across multiple threads. As we’ve seen in several posts along this series, we can use a critical regions for ensuring that shared state is accessed by one thread at a time. In other words, using a critical region ensures that access to shared state is serialized leading to correctness of the http://feedproxy.google.com/~r/Laneten/~3/wZrHw_imdPQ/multithreading-load-and-store-reordering.aspx luisabreu Mon, 29 Jun 2009 09:55:28 GMT Got a question in response to a Localization article today that asked how to store requested culture settings. In the article I recommend that easiest and most reliable way to switch cultures is to assign the culture when the application runs and allow the user to change cultures somewhere in the UI. When the culture is changed it’s up to the application to decide how to handle the actual culture change. One of the easiest things to do is write the change to a configuration setting and then exit http://feedproxy.google.com/~r/RickStrahl/~3/_-fEhZDW4YM/810709.aspx Rick Strahl Mon, 29 Jun 2009 05:28:55 GMT I wrote this for an INETA project that I have been working on, but thought it would be great to share with everyone. We had a need to take an image and change its size. Below is an implementation of a Resize Extension Method on the .NET Image object.  I borrowed some ideas from this post by Mark McDonnell (http://weblogs.asp.net/markmcdonnell/archive/2008/03/09/resize-image-before-uploading-to-server.aspx) 1: using System; 2: using System.Collections.Generic; 3: using System.L http://drowningintechnicaldebt.com/blogs/shawnweisfeld/archive/2009/06/28/extension-method-to-resize-an-image.aspx sweisfeld Sun, 28 Jun 2009 18:52:00 GMT A recent comment asked why Haskell programmers sometimes write C# lambdas in this style: Func<int, Func<int, int>> add = x=>y=>x+y; which is then invoked as sum = add(2)(3); because of course the first invocation returns a function that adds two, which is then invoked with three. Why do that instead of the more straightforward Func<int, int, int> add = (x,y)=>x+y; and invoke it as sum = add(2,3); ??? I was going to write a short article on that when I remembered tha http://blogs.msdn.com/ericlippert/archive/2009/06/25/mmm-curry.aspx Eric Lippert Thu, 25 Jun 2009 13:51:00 GMT In the last posts of the series, we’ve been looking at many important features related to GUIs and multithreading. Today, we’re going to wrap up this topic with the BackgroundWorker class. The previous posts are really targeted at library developers. The truth is that having to implement the EAP pattern  to have asynchronous behavior is simply too much work. Interact with the SynchronizationContext object to have asynchronous behavior is really too cumbersome and involves too much boilerp http://feedproxy.google.com/~r/Laneten/~3/j_IFx1iZBdU/multithreading-the-backgroundworker-class.aspx luisabreu Thu, 25 Jun 2009 10:27:34 GMT