jaredpar's WebLog : Gotcha

Type safety issue when assigning CComPtr instances

Jared Parsons — Wed, 04 Nov 2009 13:00:00 GMT

Recently while making a bug fix to our selection tracking code I discovered an unexpected behavior with CComPtr<T> instances. The crux of the fix included creating a new tracking mechanism exposed via COM in the type ISelectionTracking. The old interface, lets call it IOldTracking, was a completely unrelated interface in terms of inheritance hierarchies.

As part of the fix I changed the type of a field (m_spTracking) from CComPtr<IOldTracking> to CComPtr<ISelectionTracking>. I searched for assignments of m_spTracking and converted them to call the new API I added as part of the fix. I didn’t search terribly hard because I was depending on the compiler to catch any places I missed. ISelectionTracking and IOldTracking are incompatible types so any places I missed will show up as compilation errors.

Or so I thought …

I made my fix, ran our core check-in suites without error, checked in and moved onto the next bug. A couple hours later one of our other devs emailed me and informed me my check-in was breaking our larger, slower, suite bed run because m_spTracking was NULL. After some quick debugging I found myself looking at the following chunk of code which was apparently NULL’ing out m_spTracking in the suite.

  CComPtr<IOldTracking> spOldTracking;
  if ( SUCCEEDED(CreateOldSelectionTracking(&spOldTracking)) ) {
    m_spTracking = spOldTracking;
  }

Me and the other dev were quite shocked that this compiled at all. How is it possible to assign between CComPtr<ISelectionTracking> and CComPtr<IOldTracking>??? My first thought was I must have accidentally used a CComQIPtr somewhere (quickly verified that was not the case). After a bit of searching we found the cause was one of the operater= instances available on CComPtr<T>. Here is the definition

template <typename Q>
T* operator=(_In_ const CComPtr<Q>& lp) throw()
{
    if( !IsEqualObject(lp) )
    {
        return static_cast<T*>(AtlComQIPtrAssign((IUnknown**)&p, lp, __uuidof(T)));
    }
    return *this;
}

This templated operator allows for assignments between CComPtr instance no matter what the type is for the left and right side. The effect is that instead of doing compile type C++ type conversion rules, it will instead rely on runtime COM polymorphic assignment rules via IUnknown::QueryInterface. This moves assignment errors from compile time to runtime for unrelated interfaces.

This is further complicated because it only applies to assignment between CComPtr’s (and derived instances). If the right hand side of the assignment is a non-smart pointer, compile time C++ conversions will apply. To demonstrate …

        CComPtr<ISelectionTracking> spTracking;
        CComPtr<IOldTracking> spOld;
        ...
        spTracking = spOld;  // Fails at runtime
        spTracking = (IOldTracking*)spOld;  // Compilation Error

What surprised me though was talking to other developers about this issue. Most agreed with me that this is a bug in CComPtr<T>, or at least very unexpected behavior. A surprising number though did not expect this behavior but still considered it acceptable. The difference comes down whether you view CComPtr<T> as a simple smart pointer responsible for AddRef/Release semantics or as that plus an enabler of QueryInterface style conversions. I personally view CComPtr<T> as a simple smart pointer with know real understanding of QueryInterface style conversions and CComQIPtr<T> as a smart pointer which respects QueryInterface style conversions. As such this behavior is completely unexpected.

The fix in this case was pretty straight forward (use the new API) but I was still worried about how to prevent this type of problem in the future. In particular how to get the failure back to a compile time error. In the end we settled on using a stripped down version of CComPtr we already had in our code base going forward called CComPtrEx. I’ve previously blogged about about the need for this type here. It’s different from CComPtr in the following ways

Does not have the templated version of operator= and instead relies on compile time C++ conversions checks for assignment
Allows for interfaces which have multiple paths to IUnknown (can cause a compile time error in CComPtr).

Also for purposes of rigor, we temporarily commented out the CComPtr<T> operator, recompiled our code base and verified no new errors popped up.

Code Smell: Psychic classes

Jared Parsons — Thu, 18 Jun 2009 17:00:00 GMT

Psychic classes have the appearance of ignoring data provided to it in an attempt to provide you with an answer they predict is better for the situation. It’s impossible to look at a the data provided to an instance of the class and understand what queries on the object will return because it may think of a better answer for you, or a better piece of data to look at.

This comes from an example I ran into about a month ago. I work on an IDE and naturally deal with a lot of parse trees and tokens. Parsing everything all the time is expensive so naturally the results are cached in various places for performance reasons.

While debugging one such cache I noticed some strange behavior. The cache wasn’t returning the right tree for the input it was provided. So I decided to dig into the code a bit.

This cache takes several different forms of input which has no common base class or interface. What I noticed though is that when resetting the input of the service, it would not clear the existing cache or the previous form of input. Also because of the way the code loaded certain forms of input had precedence over others. So even an explicit clear did not guarantee the “correct” input was used.

The result is a service that reads well in code, but will not always act as you expect it to. The service at times will seemingly ignore all input and pick a source it thinks is better. Take the following code as an example

pCache->SetSource(pSomeFile);
ParseTree* pTree = pCache->GetTree();

This code is very straight forward but is certainly not guaranteed to do what it appears to do.

I like to think the service is predicting the results rather than calculating them. Or better yet guessing the answer. From the perspective of a code reviewer, that’s what’s happening.

Obviously I was curious about the reason for this and did a bit of research. It’s a rather old class so I had to contact people who’d been on the team awhile back and dig through the history of the code base to understand what the purpose of this behavior was. It turns out it was done to fix a few impactful scenarios where an alternate source needed precedence over the typical source. Other devs didn’t fully understand the source semantics of the service and wrote methods that caused bad interactions. Eventually it evolved to it’s current odd state.

Thanks to Dustin for coining the term “psychic classes”. Other ones we considered were

Jedi Mind Trick classes: Weak name
Weatherman: It’s a prediction after all

And yes, we fixed this issue :)

Is it Serializable?

Jared Parsons — Tue, 31 Mar 2009 15:00:00 GMT

I’ve recently run across several APIs that have a dependency on only dealing with objects that are serializable (in the binary sense). Unfortunately determining if an object is serializable is a non-trivial task and rife with problems. These problems have a direct impact on the types of guarantees these APIs can make.

For all objects which are serializable, it’s only possible to prove that a very small subset of them actually are in code. Easier but less reliable tests are very easy to write. So APIs must make a trade off. Only accept instances of types which are provable serializable and miss out on a while class of objects. Or do a much less reliable check and open themselves up to failure further down in the algorithm.

Take System.Exception for example. It is possible to associate arbitrary data with an exception through the Data property. Associated just any object with Exception is problematic though because Exceptions should be serializable. In order for an Exception instance to store these objects and remain serializable, the objects must also be serializable. Since serializability is not provable, the authors of Exception had to make a trade off between an overly restrictive test, or a loose test. They chose the latter. As a result it’s impossible to determine before hand if a given Exception instance is actually serializable.

Why is this the case though that serialization is tough to determine? Lets start with what it takes to make a type serializable. There are two separate components

Declaring that the type is Serializable by either having the SerializableAttribute on the class definition or by implementing ISerializable
Making the type conform to the rules of serialization.

These are completely separate actions. It’s possible to have types which do any combination of the above but not both. Take for instance the following type declarations

[Serializable]
class DeclaredOnly {
    private ConformsOnly m_conforms;
}

class ConformsOnly {
    private string m_name;
}

Both of these types are legal C# code and both represent one of the two extremes listed above. Yet neither of these types are actually serializable. ConformsOnly is not because it has not actually declared itself to be serializable. DeclaredOnly is not because one of it’s members is not serializable.

Lets look at proving serialization by ensuring types follow both of the rules. Proving the first part of serialization is pretty straight forward. Simply check to see if a type implements ISerializable or is decorated with the Serialization attribute. The latter is directly supported in the type system via Type.IsSerializable. This property is also the source of the most common mistake I see with respect to determining if an object is serializable. Take the following code snippet for an example.

public static voidExample1(object o) {
    if(o.GetType().IsSerializable) {
        // Do something different
   }
}

On the surface, this looks like reasonable code. But as we just pointed out, the property IsSerializable just determines the presence or absence of the Serializable attribute but nothing about the second part. A more descriptive attribute name would be IsSerializableAttributeDeclared. Yet many pieces of code attempt to equate this property with the ability to be serialized (A fun experiment here is to search for it’s use in Reflector)

Proving the second part involves two cases, types implementing ISerializable and types decorated with the Serializable attribute. Lets start with the attribute. Proving these is involved but a straight forward process. The type must …

Be decorated with the Serializable Attribute
One of the following items must be true for every field at all points in the hierarchy
1. It must be decorated with the NonSerializedAttribute
2. The type of the field must be sealed and must conform to all of these rules

Instances of types which meet these guidelines will always be serializable. Not meeting these rules though does not exclude a type from serialization. There are several sets of types decorated with Serializable which are serializable and do not meet these rules.

Take for instance types that violate rule 2.2. By having a field whose type is not sealed, it is possible to construct a runtime instance which contains a value whose type is not serializable. The following type fits into this category.

[Serializable]
class OnlyKnownPerInstance {
    private object m_field1;
}

Whether or not an instance of this type is serializable depends on the value of m_field1. So the only way to prove it is serializable is to look at the runtime information. This makes any definitive analysis on the type impossible. The actual object must be inspected.

The other case to examine are types implementing ISerializable. Serialization is a custom task for instances of these types and is done in imperative code. Proving these types are serializable involves actual algorithm inspection and is beyond the scope of this blog post. But suffice to say, proving these are serializable is an order of magnitude more difficult.

Getting back to the crux of this article. What is the best way to determine if an object is serializable or not? Bottom line, there is no good way. The only 100% definitive way is to serialize the object and see if it succeeds or not. This is problematic because it is not future proof. It only tells you that the object was serializable. This is a very important distinction. It’s possible for the object to be mutated in a different state later on which will prevent it from being properly serializable.

If serialization of a parameter is very important to the semantics of an API this is the only way to ensure the semantics are not violated is to serialize the object immediately and store the binary data. Otherwise you can only make a loose guarantee that an attempt to serialize in the future will succeed.

Properly handling a WinForms Timer event

Jared Parsons — Mon, 27 Oct 2008 15:00:07 GMT

The WinForms Timer class allows the user to perform a particular action at a set interval. Timer objects fire a Tick event at the set time which users can easily respond to. This is very useful if a developer wants to check for a particular condition say every 2 seconds ( for the remainder of this article I'm going to use 2 seconds as a practical example even though it's really any arbitrary time period).

Occasionally users are surprised to find that the Tick event will fire much faster than they are expecting. Instead of waiting for 2 seconds between calls, they event will fire almost immediately after one is finished processing.

What's going on here is a side effect of how this event works under the hood. The interval for the timer event is calculated in real world time. So quite literally every 2 seconds Windows will consider the internal reached and will issue a new tick message. The next time a WinForms event is not executing developer code a tick event is raised [1].

So imagine we had the following code.

Private Sub OnTimerTick() Handles m_timer.Tick
    RunSomeOperation()
End Sub

Consider what happens if RunSomeOperation takes longer than 2 seconds. The Tick event is fired in real time so while we're in the middle of RunSomeOperation, another Tick event is being queued up for processing. As soon as we leave OnTimerTick we're back in WinForms code which sees a Tick event and promptly raises it which puts us right back in OnTimerTick.

This is contrary to what most people expect. Most people expect the Tick event to fire 2 seconds after their code is finished executing.

To work around this developers should stop the timer when processing a timer event. Just before exiting the event handler, re-enable the timer. This will cause Windows to start calculating the interval from the start. This has the effect of making the timer event fire 2 seconds after developer code stops executing.

Private Sub OnTimerTick() Handles m_timer.Tick
    m_timer.Stop()
    Try
        RunSomeOperation()
    Finally
        m_timer.Start()
    End Try
End Sub

[1] This is not 100% true. It's really whenever the Application begins to pump messages again. Message pumping, more specifically when it does and does not occur, is too involved for this discussion.

Redefining Success

Jared Parsons — Fri, 24 Oct 2008 15:00:41 GMT

Spent about an hour debugging a bit of code today. I was attempting to read data from a particular source and kept getting back failure codes. After some debugging I discovered the data didn't actually exist in the source I was reading from.

This put me back to investigating where I wrote the data out. Restarted the scenario and verified that I actually called the data writing API and that it succeeded.

Now what? Well the data clearly wasn't there so I concluded the data writing must be failing in some odd way. I eventually found the data writing code and was horrified to find the following definition.

HRESULT WriteSomeData(...) {
  // We don't support data of this type
  return S_OK;
}

Personally I thought this warranted an error code (perhaps E_NOTIMPL). But given the situation I must conclude the author successfully failed to write the data.

When can you catch a StackOverflowException?

Jared Parsons — Wed, 22 Oct 2008 15:00:01 GMT

Answer: When you're the one who threw it.

Starting with the CLR version 2.0, the policy for handling a StackOverflowException was changed. User code can no longer handle the exception[1]. Instead the CLR will simply terminate the process.

This is not 100% true though. User code can still handle StackOverflowExceptions which are artificially thrown. That is thrown by the user instead of resulting from an actual overflow of the stack. This is in contradiction to the documentation but can be demonstrated with a quick and dirty sample program (see end of the post).

This is a trivial point for sure. Yet I feel the need to point it out because I recently saw a newsgroup conversation where someone posted sample exception logging code and happened to use a StackOverflowException in the sample. Their sample explicitly threw the exception so it worked and they had good reason to suspect it worked in production as well. I was equally amazed it worked at all.

Please don't take this post as advocating that you should handle a StackOverflowException (you shouldn't). This is merely an oddity I found interesting. Personally I'd prefer it not be catch-able in any circumstance.

public static void CatchStackOverflow1() {
    try {
        throw new StackOverflowException();
    } catch (StackOverflowException ex) {
        // Executes and handles the exception.  User code continues
        Console.WriteLine(ex.Message);
    }
}

static int CreateRealOverflow(int p1) {
    return 42 + CreateRealOverflow(p1 + 1);
}

public static void CatchStackOverflow2() {
    try {
        CreateRealOverflow(42);
    } catch (StackOverflowException ex) {
        // Will not execute
        Console.WriteLine(ex.Message);
    }
}

static void Main(string[] args) {
    CatchStackOverflow1();
    CatchStackOverflow2();
}

[1] Unless you are hosting the CLR in which case you can implement some recovery mechanism. This is certainly the exception though and not the rule [2]

[2] Sorry for the pun

Regular Expression Limitations

Jared Parsons — Wed, 15 Oct 2008 15:00:00 GMT

I'm struggling with an introduction line to this blog post so I'm just going to go for bluntness: Regular expressions are limited and it's important to understand these limitations. Ok, now that the premise is out of the way, lets go to a sample.

For a time in college I was a teaching assistant in a introduction to Compiler course [1]. Regex's played a large role in the class and inevitably a question or two would appear on a test and the final. My favorite question was the following

Imagine the C block comment token (/* */) was allowed to be recursive. For example /* /* this is a comment */ */. Write a regex which will match all C comments.

We'd get loads of interesting answers but there is only one correct one. It's not possible.

Why? The keyword in this question is "recursive." I prefer to call it "counting" though. Regular expressions a class of Finite Automata (FA). One of the properties of FA is they cannot be asked to match anything that is recursive (aka has the equal number of items on left hand side and right hand side). They lack the sufficient state necessary to do so. To accurately match this a Context Free Grammar is required. Enough with the terminology though.

Critics: Wait, you think asking a trick question on a test is a good idea?

Answer: At first no. I didn't like this question when I encountered it as a student and it took me a precious 10 minutes to answer. I knew the answer right off the bat but I was hesitant to write it down. As a TA I liked this question slightly more. Namely because we drilled on this point from day 1 and most students would still miss the question [2].

I didn't truly appreciate this question until I started working professionally. I often see people struggling to create a functioning regex for patterns that it cannot possibly work for. One of the first places I saw it was in a piece of code that QA was (naturally) having a field day with. I was brought it for a code review and after seeing the regex and the problem I pointed out that it wouldn't be possible. It took a few minutes but I was able to convince them a regex wouldn't work. Up until that point no one had considered there wasn't a regex solution, just that the one they had wasn't good enough. Days were wasted in this venture.

Part of being a good programmer is recognizing the strengths and weakness's of your tools. Most importantly though is knowing the limitations. It will save you hours and potentially days of wasted work.

As an exercise which of the following can a regex help with (answer at bottom under [3])?

A C# string
A C# string literal
An XML element
An XML attribute
A file system path
A C/VB/C# math expression
Email address
Matching a valid regex

As a side note, there are several regex engines out there that support the notion of recursion. These will allow you to match these types of patterns but are not technically regexs in the strictest since of the word. These are not strictly speaking regular expressions in computing theory but recursive extensions are quickly becoming a part of many libraries.

In a future (hopefully soon) post I will explore the recursive extensions to the .Net regular expression language.

[1] It had various names CS2330 is the most infamous

[2] Even though we would go over it verbatim in class

[3] Regex will work for 1,2,4,5,7

A Lesson in Serialization

Jared Parsons — Tue, 02 Sep 2008 15:00:46 GMT

A few days ago, I recklessly added a [Serialization] attribute to a few of my immutable collection types. I needed to pass data between AppDomain's and adding [Serialization] was the quick and dirty fix. Compiled, ran and I didn't think much about it.

Luckily I was updating some unit tests last night and I remembered this and added a couple of serialization sanity tests. Most of the tests passed first time but for my ImmutableStack class[1] was throwing an exception. Well, it was actually my ImmutableQueue but it was failing in one of the inner ImmutableStack instances. The test code was fairly straight forward

var stack = ImmutableStack.Create(new int[] { 1, 2, 3 });
using (var stream = new MemoryStream()) {
    var f = new BinaryFormatter();
    f.Serialize(stream,stack);
    stream.Position = 0;
    var obj = f.Deserialize(stream);
    var stack2 = (ImmutableStack<int>)obj;
    var stack3 = stack2.Reverse();
}

I did a bit of digging and discovered the exception was coming from the stack2.Reverse() call. Jumped through the code and didn't see much wrong. I had several existing tests around ImmutableStack.Reverse() and I couldn't see why Serialization would make any difference.

public ImmutableStack<T> Reverse() {
    var r = ImmutableStack<T>.Empty;
    var current = this;
    while (current != ImmutableStack<T>.Empty) {
        r = r.Push(current.Peek());
        current = current.Pop();
    }

    return r;
}

Can you see what's wrong with the code?

It took me a few minutes of debugging and frustration. The bug is in the while loop conditional. Until you introduce serialization this code is just fine. ImmutableStack<T>.Empty is a static readonly declaration. The code implementation only allows for one to be created so it a singleton and equality can be done with a quick reference check.

private static readonly EmptyImmutableStack s_empty = new EmptyImmutableStack();

public static ImmutableStack<T> Empty {
    get { return s_empty; }
}

Unfortunately serialization breaks the assumption that EmptyImmutableStack is a singleton. The EmptyImmutableStack class is a singleton by convention only. It's a private nested class that's only instantiated once per AppDomain. There is nothing stopping the CLR or Serialization for that matter from creating a second instance. In the case of deserialization that's exactly what happens. The serializer isn't built to recognize this pattern and instead simply creates a new instance of EmptyImmutableStack upon deserialization.

This essentially prevents you from safely using a functional style Empty pattern inside a serializable collection.

The fix is simple enough, alter the conditional to be (!current.IsEmpty).

[1] The version of ImmutableStack I'm using is heavily based off of Eric Lippert's implementation.

Don't mix using statements and lambda expressions

Jared Parsons — Wed, 16 Jul 2008 15:00:00 GMT

Title pretty much says it all but what good is a rule without any explanation. The main issue here is that at the core, using statements and lambda expressions both alter variable lifetimes. Unfortunately they alter the lifetime in different directions. Using will shorten the life time of a variable to the specified block. This is a somewhat artificial way because the object is still technically alive but can't be trusted to do anything. Lambda expressions take a variable limited to a specific scope and extends their lifetime to potentially be that of a heap value. Anytime two features alter the attribute of a variable in different directions, they can probably cause problems when used in conjunction.

Take the following contrived but real example.

        static Future<int> Example() {
            using (var obj = new MyDisosableObject()) {
                return Future.Create(() => obj.SomeFunction());
            }
        }

Bit by void*

Jared Parsons — Mon, 16 Jun 2008 15:00:07 GMT

Recently I got bit by void* again because of another C++ quirk I didn't think through. I had a class which wrapped a void* which could be one of many different structs. The structs were POD and didn't have any shared functionality hence I didn't bother creating an inheritance hierarchy. Unfortunately I defined the structs like so

class C1 {
  struct S1 {
    int field1;
    float field2;
  };
  struct S2 {
    char field1;
  };
  ~C1() {
    delete m_pData;
  }
  void* m_pData; // Can be S1,S2,etc ...
}

Unfortunately this appeared to work fine for quite some time. Then after a couple of days of bug fixes I ended up with a memory leak which I quickly tracked down to a leaked COM object. Although C1 was at fault I didn't suspect any changes to this class because after all it was working fine for some time and all I did was add a new field to one of the structs. If the structs were being successfully free'd before a new field shouldn't change anything.

The field I added was of type CComPtr<T> which exposed a greater problem in my code. Even though I properly delete the pointer in C1::~C1() I wasn't running the destructor on the pointed at data and instead I was just freeing the memory. Until I added a field which had a non-trivial destructor this wasn't a problem (still a bug though).

Why did this happen? By deleting a void* and expecting a destructor to run what I'm really doing is asking C++ to behave polymorphicly. C++ as a rule won't behave this way unless it is specifically asked to with inheritance and virtual. In the case of void*, it just won't. The fix is to actually implement an inheritance hierarchy which supports polymorphism.

It's just another rule that I need to remember when coding C++.

Deleting void* is dangerous, period.

Unfortunately C++ has too many of these rules and not enough enforcement.

Gotcha: CComAutoCriticalSection and copy constructors

Jared Parsons — Thu, 24 Apr 2008 15:00:24 GMT

While investigating a crash during a suite run I found the stack walk included the destructor for a CComAutoCriticalSection. This is a fairly reliable class so I immediately suspected my code. I did a couple of quick checks for a double free and didn't find any. Then I looked a little closer at CComAutoCriticalSection and spotted that it doesn't redefine the standard copy and operator= constructor.

This is a red flag for any class that implements RAII. C++ will automatically define a copy/operator= for your clasess which will amount to a memcpy. This means copies of two objects will be managing the same resource. Once the second one is destroyed it will result in a double free and hopefully a crash.

I walked the hierarchy and discovered that none of the base classes redefined these methods either. After that it only took a few minutes to discover the bug. I attempt to pass the object by reference but instead ended up passing it by value.

To ensure I didn't miss any other cases of this, I added the following definition to my code base and moved all instances of CComAutoCriticalSection to point to this version.

class SafeCriticalSection : public CComAutoCriticalSection
{
public:
    SafeCriticalSection() {}
private:
    SafeCriticalSection(const SafeCriticalSection&);
    SafeCriticalSection& operator=(const SafeCriticalSection&);
};

It should be standard practice to define all 3 of the above methods on any class which has RAII semantics. This is not necessary if all of the members are copy safe (CComPtr<> for example).

Immutability and ReadOnlyCollection

Jared Parsons — Tue, 22 Apr 2008 15:42:00 GMT

I am a huge fan of read only/immutable collections and data. Hopefully the increased exposure through the blogosphere alerted users to the advantages of this type of programming for the appropriate scenarios. I wanted to discuss ReadOnlyCollection<T> in case devs looking around in the BCL discover it and assume it's immutable. There are two details of this class which cause gotchas and design issues for consumers who assume it is immutable.

It implements IList<T>

IList<T> is a interface describing mutable collection types which support indexing. ReadOnlyCollection is designed to be read only and cannot fulfill this contract. Therfore every mutable function will throw an exception. IMHO this is not the best design because it is implementing a contract it won't every fullfill. This has the effect of turning what should be a compile time error into a runtime exception (passing a non-mutable collection to an API expecting a mutable collection).

Unfortunately there is not a good interface to implement. The indexable interfaces are all representative of mutable collection types. It would be nice to add an immutable/read only interface which can be safely implemented.

    interface IReadOnlyList<T> : IEnumerable<T>
    {
        T this[int index] { get; }
        int Count { get; }
        int IndexOf(T value);
        bool Contains(T item);
        void CopyTo(T[] array, int arrayIndex);
    }

Ideally this would be called IImmutableList<T> but I'm having trouble getting over the double I, double M pattern to start the name. Perhaps IPersistentList.

It's not deeply ReadOnly

ReadOnlyCollection<T> is a read only facade on top of mutable collection. Read only data should be just that, read only. This means calling methods directly on the class produce the same result every single time. However because it uses a mutable backing store this is not true and can cause gotchas along the road.

Take the following sample which uses a ReadOnlyCollection to wrap a List.

            var list = new List<int>();
            list.AddRange(Enumerable.Range(1, 10));

            var roList = new ReadOnlyCollection<int>(list);
            Console.WriteLine(roList.Count);    // Outputs: 10
            list.Add(42);
            Console.WriteLine(roList.Count);    // Outputs: 11

There are ways to avoid this problem with ReadOnlyCollectionn. The simplest is to make sure you pass a copy of your list into the constructor.

            var roList2 = new ReadOnlyCollection<int>(new List<int>(list));

Gotcha: Generic overload resolution when called generically

Jared Parsons — Mon, 14 Apr 2008 15:30:07 GMT

Both VB and C# have a feature of generic overload resolution that is fairly helpful and yet a source of gotchas. Lets say you have two methods with the same number of arguments. One method has arguments with generic types and the other does not. For Example:

    class C1<T> {
        public void F1(int ival) {
            Console.WriteLine("Non-generic F1");
        }
        public void F1(T val) {
            Console.WriteLine("Generic F1");
        }
    }

Imagine what happens when we have a C1<int> and call F1(5). Which method should the compiler bind to? Both VB and C# when presented with this type of situation will choose the non-generic version.

            v1.F1(5);           // Binds to Non-generic F1
            v2.F1("foo");       // Binds to Generic F1

At a glance we might think that we can provide specialized behavior for a subset of types that are interesting (similar to C++ template specialization). If VB/C# will bind to our non-generic version then we don't have to due ugly type switching to implement different behavior for certain types. Unfortunately we would be wrong.

This type of overload resolution only happens if the compiler can statically verify that the argument matches a non-generic overload. So if we call F1 generically it will not bind to the non-generic overload.

        static void TestOverload<T>(C1<T> weird, T value) {
            weird.F1(value);
        }

        static void Main(string[] args) {
            var v1 = new C1<int>();
            var v2 = new C1<string>();

            TestOverload(v1, 5);        // Binds to Generic F1
            TestOverload(v2, "foo");    // Binds to Generic F1
        }

Gotcha: CComPtrBase assignment

Jared Parsons — Tue, 08 Apr 2008 18:44:16 GMT

Today what started out as a crash due to a pure virtual call turned into finding a gotcha in CComPtrBase<T>. Essentially the code in question boiled down to the following. Can you spot the problem?

void GetAStudent(CComPtrBase<T> &spStudent)
{
    CComPtr<Student> spLocal;
    // Do some operation to get a student
    spLocal = spStudent;
}

The problem isn't apparent until you look at the definition for CComPtrBase<T>::operater =. See the problem? Basically CComPtrBase<T>::operator= isn't explicitly defined. This means that C++ will automatically implement memberwise assignment. The RHS of the operator= will be a "const CComPtrBase<T>&".

CComPtr<T> derives from CComPtrBase<T> therefore it satisfies this and a memberwise assignment will occur. We now have two smart pointers on the same value. However the second smart pointer, CComPtrBase<T>, did not perform an AddRef. So when both objects are destroyed there will be an extra Release and hopefully a crash.

The fix?

Use CComPtr<T> or CComPtrEx<T> instead of CComPtrBase<T>
Less Optimal: call AddRef() on spLocal.

Get-Content and File Names

Jared Parsons — Sat, 02 Feb 2008 21:55:21 GMT

Another day, another PowerShell feature discovered. Unfortunately this time it was a feature that made me think I had a bug in my script. The script read through some directories, did some file parsing and created a data object for every directory in the form of a Tuple.

One of the files was People.txt and contained a list of relevant people for the data (one per line). Unfortunately the parameter kept showing up like so ...

People
------
{People.txt, People.txt, People.txt, People.txt}

Confusion set in as to what I did wrong since the code in question amounted to the following.

D:\temp> new-tuple "People",(gc People.txt)

Next step is manual verification

D:\temp> gc People.txt
jared
jamie
jason
mary

So far so good. Then a tried the explicit tuple code and got back the People.txt problem. Eventually I decided to try out get-member and see exactly what I had in the array. It was a string type as expected but then I noticed the following ... extra items.

D:\temp> gc People.txt | gm

TypeName: System.String

Name MemberType Definition
---- ---------- ----------
...

PSParentPath     NoteProperty          System.String PSParentPath=D:\temp
PSPath           NoteProperty          System.String PSPath=D:\temp\People.txt
PSProvider       NoteProperty          System.Management.Automation.Provider...
ReadCount        NoteProperty          System.Int64 ReadCount=1

It turns out that when you read information from a file in PowerShell they will handily add in the file information as NoteProperty instances. All well and good and I can see where that would be useful but for now it's really messing up my display. To remove it just tell powershell that I really just want a string.

D:\temp> new-tuple "People",(gc People.txt | %{[string]$_})

People
------
{jared, jamie, jason, mary}