CSharpDevCenter

C# 4.0: dynamic<T> ?

By jonskeet

I’ve not played with the VS2010 CTP much yet, and I’ve only looked briefly at the documentation and blogs about the new C# 4.0 dynamic type, but a thought occurred to me: why not have the option of making it generic as a way of saying “I will dynamically support this set of operations”? As an example of what I mean, suppose you have an interface IMessageRouter like this: public interface IMessageRouter{    void Send(string message, string destination);} (This is an arbitrary example, by the way. The idea isn’t specifically more suitable for message routing than anything else.) I may have various … Continue reading C# 4.0: dynamic<T> ?

DeveloperDeveloperDeveloper: Registration now open (hurry!)

By jonskeet

The registration page for DeveloperDeveloperDeveloper Day 2008 (Reading, November 22nd) is now open. In the past this has been heavily oversubscribed, so if you want to come you’ll need to register quickly. I’ve got a speaking slot in the afternoon: implementing LINQ to Objects in 60 minutes. As always, I’m very much looking forward to it.

Mapping from a type to an instance of that type

By jonskeet

A question came up on Stack Overflow yesterday which I’ve had to deal with myself before now. There are times when it’s helpful to have one value per type, and that value should be an instance of that type. To express it in pseudo-code, you want an IDictionary<typeof(T), T> except with T varying across all possible types. Indeed, this came up in Protocol Buffers at least once, I believe. .NET generics don’t have any way of expressing this, and you end up with boxing and a cast. I decided to encapsulate this (in MiscUtil of course, although it’s not in … Continue reading Mapping from a type to an instance of that type

Why boxing doesn’t keep me awake at nights

By jonskeet

I’m currently reading the (generally excellent) CLR via C#, and I’ve recently hit the section on boxing. Why is it that authors feel they have to scaremonger about the effects boxing can have on performance? Here’s a piece of code from the book: using System; public sealed class Program {   public static void Main() {      Int32 v = 5;   // Create an unboxed value type variable. #if INEFFICIENT      // When compiling the following line, v is boxed      // three times, wasting time and memory      Console.WriteLine(“{0}, {1}, {2}”, v, v, v);#else      // The lines below have the same result, execute      // much faster, and use … Continue reading Why boxing doesn’t keep me awake at nights

Non-nullable reference types

By jonskeet

I suspect this has been done several times before, but on my way home this evening I considered what would be needed for the reverse of nullable value types – non-nullable reference types. I’ve had a play with an initial implementation in MiscUtil (not in the currently released version) and it basically boils down (after removing comments, equality etc) to this: public struct NonNullable<T> where T : class{    private readonly T value;     public NonNullable(T value)    {        if (value == null)        {            throw new ArgumentNullException(“value”);        }        this.value = value;    }     public T Value    {        get        {            if (value == null)            {                throw new … Continue reading Non-nullable reference types

Formatting strings

By jonskeet

A while ago I wrote an article about StringBuilder and a reader mailed me to ask about the efficiency of using String.Format instead. This reminded me of a bone I have to pick with the BCL. Whenever we make a call to String.Format, it has to parse the format string. That doesn’t sound too bad, but string formatting can be used a heck of a lot – and the format is almost always hard-coded in some way. It may be loaded from a resource file instead of being embedded directly in the source code, but it’s not going to change … Continue reading Formatting strings

Lessons learned from Protocol Buffers, part 4: static interfaces

By jonskeet

Warning: During this entire post, I will use the word static to mean “relating to a type instead of an instance”. This isn’t a strictly accurate use but I believe it’s what most developers actually think of when they hear the word. A few members of the interfaces in Protocol Buffers have no logical reason to act on instances of their types. The message interface has members to return the message’s type descriptor (the PB equivalent of System.Type), the default instance for the message type, and a builder for the message type. The builder interface copies the first two of … Continue reading Lessons learned from Protocol Buffers, part 4: static interfaces

Lessons learned from Protocol Buffers, part 3: generic type relationships

By jonskeet

In part 2 of this series we saw how the message and builder interfaces were self-referential in order to allow the implementation types to be part of the API. That’s one sort of relationship, but in this post we’ll see how the two interfaces relate to each other. If you remember from part 1 every generated message type has a corresponding builder type. As it happens, this is implemented with a nested type, so if you had a Person message, the generated types would be Person and Person.Builder (in a specified namespace, of course). Without any interfaces involved, this would … Continue reading Lessons learned from Protocol Buffers, part 3: generic type relationships

Lessons learned from Protocol Buffers, part 2: self-referential generic types

By jonskeet

In the first part of this series we saw that a message type and its builder are closely related. The tricky bit comes when we want to define an interface describing messages and builders. Although some members clearly depend on the data being built (the first and last name in the person example above, for instance) others apply to all messages or all builders. For instance, a message can always provide you with a suitable builder, and a builder always allows you to build it to create the actual message. Likewise the message and builder types also have methods which … Continue reading Lessons learned from Protocol Buffers, part 2: self-referential generic types

Lessons learned from Protocol Buffers, part 1: messages, builders and immutability

By jonskeet

My port of the Protocol Buffers project has proved pretty interesting. I thought I’d share some of the lessons I’ve learned along the way, as well as some of the frustrations at concepts I still can’t express in C#. This was originally all going to be in one post, but I’m becoming acutely aware of how long some posts can grow. I don’t know about you, but I find very long blog posts quite intimidating, so I’ve decided to split them up into individual topics. You’ll still probably need to read the posts in order to understand them though – … Continue reading Lessons learned from Protocol Buffers, part 1: messages, builders and immutability