A Meandering Static Locals Story
December 20th, 2005
I was writing some C# code the other day and attempted to use a static local variable. This may only be because I’ve been spending so much time with C++ recently, but I was very surprised to find that it didn’t work. “That’s a shame,” I thought. It’s not as though I use static locals every day. I’ve been using C# for a few years and I was just getting around to discovering that it doesn’t support them, after all. Nevertheless, I would say I use static locals exactly when I need them.
I was sure that VB.NET supported static locals. I thought that perhaps an Object Orientation zealot decreed that they weren’t going into C#, even though that would not be typical of the attitude exhibited in the most recent C# whitepapers. As it turns out, that’s not what happened at all. Static locals are a compiler feature, and not something implemented on the CLR level. Paul Vick explains:
Implementing static locals in the compiler was a gigantic pain in the ass, and we had a lot of arguments about whether they were worth the effort. There are times that I haven’t been entirely convinced about it, but I think my thoughts on this are changing…
I suppose I have already conceded that there are more important things to spend time on. In the same post Paul discusses the relative merits of the keywords in either language.
We also felt that “Shared” is a lot more descriptive than “Static,” and I wonder whether C# would have chosen that term if they hadn’t been stuck with the legacy of C, but… This is probably the most painful keyword divergence between the two languages in terms of documentation.
Something of a silly discussion, I think, since VB is teeming with its own historical oddities (to wit: Dim intArray(0) As Integer
). But this does remind me of a story.
A while back I was debugging an odd issue where users of a web application were seeing each other’s data “randomly.” Our application has a set of links on one side of it that are customized to relate to the entity the user is viewing. A typical bug would be:
The top half of the links relate to entity ‘A’ (which is the right one), but the bottom half of the links relate to entity ‘B,’ which I was not looking at.
Compared to some other bugs I have worked on, this one was a piece of cake. I figured out pretty quickly that the developer of the control in question had written a big section of variables that looked like this:
Public Shared A As Integer
Public Shared B As String
Public Shared C As String
' ...;
These were used in the process of rendering the hyperlinks. I asked the developer why he’d done this, but he didn’t know why. He had just seen the word “Shared” associated with member declarations in the past and thought that he needed to put it there.
He was typically more informed about keywords than this, so telling him that Shared was like “static” in other languages brought instant recognition. In fact he changed the code so that it looked like this (I’m doing this from memory, but I think this is pretty faithful to the original treasure):
' Shared == Static!! Shared variables are static!
Public A As Integer
Public B As String
Public C As String
' ...;