DirectCast revealed

Since I’m on the cusp of rewriting the section in the VB language spec on DirectCast so that it actually tries to make sense, I thought I’d talk about it here, since I don’t know how much people understand about this strange little operator. DirectCast is a cast operator that has the same syntax as CType and is useful in some narrow situations. But first, a little background…

You may have noticed that all VB.NET projects get a default reference to Microsoft.VisualBasic.DLL. It doesn’t show up in your list of references because you can’t remove it. Why? Because it isn’t possible to express all of the VB language in IL, so we sometimes have to rely on helper functions. A good example of this is conversions from Object. If you convert an Integer to Object, for example, the CLR will only let you convert it back to Integer. However, VB will allow you to convert it back to Long, Double, String, etc. To make this work, the compiler emits a conversion from Object as a call to a helper function. The helper function takes the Object, looks at the type of the value contained in it and then does the appropriate conversion to the target type.

When we started working on Microsoft.VisualBasic.DLL, we decided to write all the language helpers (and all the familiar user functions like Left, Right, Mid, etc) in VB. In addition to the fact that we like VB, it’s also a great way to dogfood the product. So we set about writing the helpers, but we quickly ran into a chicken-and-egg problem. Let’s say that we’re writing the helper that converts something typed as Object to Integer. It would contain code something like:

If TypeOf o Is Integer Then
    Return CInt(o)
End If

See the problem? The CInt(o) conversion tries to convert something typed as Object to Integer… which is going to call the helper again. And again. And again. Until you run out of stack space and die. The problem was there was no way to “escape” from the extra VB conversion semantics and say “just cast this directly to x type, forget about all the fancy stuff.” And that’s where DirectCast comes in. The function of DirectCast is to just give you the CLR supported conversions and none of the extra conversions that VB supports by use of a helper. So when you say DirectCast(o, Integer), if o does not contain an Integer, you’ll get an exception, whereas CType(o, Integer) will work if o contains a Long, Double, String, etc. As you can imagine, we use this all over the place in our helpers.

Ok, so now you’re asking: “So why isn’t this just something you hacked in for building your runtime? Why did you make it a full part of the language?” Well, one reason was that we wanted to follow the principle that we didn’t want to have to “cheat” to build our runtime – presumably, if we needed to do something, others might, too. (There are still a few minor cheats that we make when building our runtime, but that’s another blog entry.) And, as it turns out, there are some narrow situations where using DirectCast can make things a tiny bit fast than they might otherwise be. Essentially, if you know that what you’re converting is exactly what you say it is, then you can use DirectCast to bypass the little bit of overhead that you incur by using the runtime helper. The most common place I use it in my own code is when dealing with collections like ArrayList:

Dim a As New ArrayList()
Dim i As Integer
i = DirectCast(a(0), Integer)

In this case, I know that the thing I’m getting out of the ArrayList is an Integer, so I skip the helper and go straight to DirectCast. However, I only suggestion you use this in situations where you know it will work, and you think you need that extra little bit of performance. In the real world, you’re hardly ever going to notice the difference, so you might as well go with the more flexible conversion operators like CType, CInt, etc. But when you identify some place you need that extra little “oomph,” it can come in handy.

Another thing I’m going to have to get to…

Frans has a very interesting reply to an entry by Roy. A lot of it is about particular design aspects of one language versus the other, which I think people can argue about forever and ever, but what caught my eye was:

I personally think Microsoft has made a mistake by introducing VB.NET. The reason for this is that VB.NET creates a serious positioning problem: what’s the real difference between C# and VB.NET besides some language definitions? Is one the real RAD tool and the other for the keyboard-lovers who like to do everything the hard way? Why does one have XYZ and the other does not and vice versa? I don’t see it why they’ve created these problems in the first place. […] I therefor won’t be surprised when Microsoft phases out VB.NET in the long run over C# […]

My first reaction to the question “Why did Microsoft create VB.NET?” is always to think of Louis Armstrong’s response when he was asked to explain jazz: “Man, if you gotta ask, you’ll never know.” And then my second reaction is: if you use VB.NET and
VC#.NET for a while, you’ll quickly realize that they are not just the same language with different syntax. To use a phrase that will date me, they each have a very distinct “look and feel” that goes beyond which features each language supports, and this look and feel is has significance. (To riff off my Louis Armstrong reference, to me VB feels a lot like jazz, while VC# feels a lot like classical music.)

But I realize all this touchy-feely stuff doesn’t really answer the question. It’s definitely something I’m working on nailing down because I think it’s vital that we be able to articulate it in a better way than we have in the past. And out of that explanation should flow the reality that VB.NET isn’t going anywhere in the short term or the long run. The free market, of course, gets the final word (as always), but we’re going to continue to bang away hard on new versions of VB.NET as long as there are people who are going to use them…

Finding the balance

OK, so I’m just following the latest trend at Microsoft – even though my first post is conveniently dated several days before this article. Now I’m just left hoping that I’m not the one that “blow[s] it for everybody else” (as Joshua Allen succintly put it).

This blog is a bit of a mix. It runs on hardware and software that I purchased with my own dime and is physically located in my basement in an old armoire (which my wife insists on calling a “chiffarobe,” like some character from “To Kill a Mockinbird”). On the other hand, I’m naturally going to talk about what I spend a lot of my day doing, and I will occasionally post on company time, like right now. So it’s going to be a delicate balance, and one that I’ve obviously been thinking about for a long time.

Back in my salad days of uber-geekdom (i.e. in my early teen years before I discovered the opposite sex), I was a Doctor Who fanatic. As such, I naturally owned a highly prized Tom Baker-esque wool multicolored scarf, to which I would affix various Doctor Who related buttons. One of the few that wasn’t Doctor Who related (and the whole point of this story) was one that read “Proudly Serving My Corporate Masters.” I think that about sums up my relationship with my employer: I’m basically a semi-sellout who really enjoys working for the Man and everything that comes with it, but who nonetheless likes to pretend that he can also be his own man, with a little “m.” Am I fooling myself? Depends on who you ask, I guess…

[Ed. note: I am extremely frightened to find that a quick search on Google reveals
that an ex-Microsoftie has written a book called “Proudly Serving My Corporate Masters.” Am I really that unoriginal? As it turns out, maybe. The author tracks down where the phrase came from, and… there’s my button!]

An interesting story…

I was going to avoid the sensitive subject of the VB6 to VB.NET upgrade for a while – you know, get my feet wet before tackling anything difficult – but my hand has been forced. Robert Scoble posted a story about the competition between Canon and Nikon that made me think of that particular controversy. The quotes that I found most interesting were:

So, how did Canon get in? Easy, they changed their lens mount. Whoa, wouldn’t that piss off professionals? After all, do you know how much a 300mm F2.8 lens is? About $4000. Wouldn’t people rebel against “lock in?” Especially “lock in” that demonstrated the company didn’t see much value in keeping their lens mount the same?


But, do you think that professional photographers didn’t hate Canon for changing their lens mount and taking an approach toward its customers that said “we’re gonna obsolete you, and make all your old stuff worthless so we can make a better product?” Heck yes! But, funny thing about customers. They buy a better product.

I don’t draw any particular conclusions from the story (after all, Nikon could have just improved their autofocus without changing their lens mount), but it does have interesting intersections. Anyway, I’m sure I’ll have more to say about this as we go along.

About the author

Like personal ads and job application cover letters, a weblog introduction entry is bound to be awkward, a bit stilted and vaguely self-aggrandizing. So let’s get it over with as quickly as possible, shall we?

I am the author of this weblog, and my name is Paul Vick. Since this weblog will most likely be more oriented towards the technical than the personal, I’ll start with the professional side of my life: my current job is Technical Lead on the Visual Basic .NET product at Microsoft, although I’ve been around Microsoft long enough now (11 years and counting) to have done a variety of things. I’ve been on the Visual Basic team for 6 years now, most of it closely associated with the core Visual Basic compiler (as opposed to, say, the data access components, debugger or IDE). For a long while, my primary responsibility has been overseeing the development of the compiler (I’m a programmer), but recently I’ve been focusing more on the design aspects of the language and the broader product. Oh, and I’m the author of the Visual Basic .NET Language Specification, which I add because it’s probably the most tangible result of my work of the past several years. (I’m also working on a Visual Basic language reference book, but believe that when you see it…)

On the personal front, I live in Seattle, WA with my wife and two cats. I do have a life outside of work, but I think I’ll let those details come into the weblog naturally rather than making this entry really start sounding like a personal ad…