Category Archives: Visual Basic

vbc.rsp, coming in VB 2005!

2 Replies

Jay’s blog entry on references and such reminded me of another small feature that we’re doing for VB 2005, the default response file for vbc.exe. Basically, this feature makes the VB command-line compiler work in pretty much the same way that the C# command-line compiler works today: there is going to be a file vbc.rsp that sits with the command-line compiler and includes a lot of default settings for compilation, mainly references and imports. If you don’t want the default response file, you can specify the /noconfig switch and we won’t load the default settings.

Jay’s main point, though, is about the difficulty of getting to classes that you know must exist but which you don’t have a reference or import for yet. He suggests that projects by default should reference the entire framework but this won’t work, at least for VB. I’ve been doing quite a bit of work looking at how long it takes to create a new WinForms project in Whidbey and it turns out that the Frameworks DLLs are big and getting bigger. Just loading all the symbols out of them so that we can do Intellisense and code model stuff consumes quite a bit of memory. So the thought of referencing even more DLLs makes me shudder – C#’s Intellisense/code model engine might be different, but for VB the “small performance impact” would be very big. Unless, of course, you’ve got gobs of available memory, which we all have, right?

That said, it seems like there are other ways we could attack the problems of adding references and of adding imports. This is of particular importance to VB because of the fact that the My namespace is intended to aggregate functionality from across the Framework. How do we deal with My.Foobar, if you don’t have a reference to System.Foobar.DLL yet? So I think we’ve still got some work to do on that point.

Lordy, lordy, BASIC’s forty!

Leave a reply

I had nearly forgotten that we’re approaching a major milestone this weekend – the 40th anniversary of the first BASIC program! Happy birthday, BASIC!

I only remembered the occasion because the AP Newswire did a story on the anniversary and they wanted to get a quote from someone at Microsoft about BASIC. They wanted Bill Gates, but they got me – too bad for them! Anyway, I had a very pleasant chat with the reporter about BASIC and Microsoft and such. Although I see where he’s coming from with the idea that BASIC is no longer with us – certainly not in the original, 1964 version, at least – I still like to think that the spirit of BASIC lives on strong in Visual Basic and all the other BASIC inheritors out there…

Thanks, John Kemeny and Thomas Kurtz!

The My namespace and C#

18 Replies

Don and Robert ask in comments to my previous entry, “Will C# be able to use the My namespace?” The answer is: yes and no.

Most of the functionality contained in My is implemented by types that will be defined in Microsoft.VisualBasic.DLL. So C# users are welcome to reference the DLL and use types such as System.IO.FileSystem or Microsoft.VisualBasic.MyServices.MyComputer. Besides the cognitive dissonance of having to actually use the name “VisualBasic,” there’s really no difficulty there.

However, the top level “glue” that brings all the My pieces together is something that’s compiler-specific and so C# users won’t see it. The top-level My stuff is compiler-specific for two reasons:

  • The My types exposed in a particular project are dependent on the type of the project. A web service project will have a different My namespace than a WinForms project will. Thus, the top-level definition of My has to be integrated into the actual building of the project.
  • Pieces of the My namespace (such as My.Forms) are dependent on objects that are actually a part of the project itself. Thus, the compiler has to specially generate those pieces of the My namespace at compile time.

Roy raises the question as to whether divergence between the languages like this is a good thing or a bad thing. While I’m sympathetic to his point about increased difficulties moving between two languages, it does raise the question: what’s the point of having two separate languages if they have exactly the same set of features? Case insensitivity vs. case sensitvity, for example, is not reason enough alone for Microsoft to invest all the money that it does building both products.

Ultimately, feature set comparability has to be a balancing act between innovation and knowledge portability. If C# and VB cannot implement a new feature without the other language implementing it, the user ultimately suffers by way of reduced language innovation. It would be hard to argue that VB users should not get Edit and Continue back because C# doesn’t plan to support it in Whidbey. Similarly, should C# users not get anonymous methods because VB doesn’t plan to support them in Whidbey? Inevitably, the best ideas of one language will be cribbed by the other language. If My turns out to be a smashing success, I’d expect C# to come sniffing ’round it the next time around. Certainly we’re watching how iterators and anonymous methods play out as we think about features for the future.

Innovation, however, does come at a cost and that can’t be ignored. But I think, in the end, the cost is worth it to both languages’ users.

Static locals are cool

18 Replies

Or so says a sticky note that I stuck on my monitor on Friday to remind me to blog about them. Static locals are local variables whose values are preserved across calls to a method. For example, the following method will print the sequence 0, 1, 2, 3, 4, 5, 6, etc. on successive calls:

Sub PrintNextNumber()
    Static x As Integer = 0

    Console.WriteLine(x)
    x += 1
End Sub

What basically happens with static locals is that we create a hidden field in the containing class to store the value across calls to the method. Thus, static locals are really most useful when you have a type-level value that you need to store that you want only scoped to a particular method. I thought to blog about this because I was working on finalizing my managed VB parser sample and I needed to have a lookup table for type characters when scanning type characters. I could have written it as:

Class Scanner
    Private _TypeCharacterTable As Hashtable
    Private ReadOnly Property TypeCharacterTable As HashTable
        Get
            If _TypeCharacterTable Is Nothing Then
                ... initialize table ...
            End If

            Return _TypeCharacterTable
        End Get
    End Property

    Private Function IsTypeCharacter(ByVal c As Char) As TypeCharacter
        Return _TypeCharacterTable(c)
    End Function
End Class

But with static locals, you can be more compact:

Class Scanner
    Private Function IsTypeCharacter(ByVal c As Char) As TypeCharacter
        Static TypeCharacterTable As Hashtable

        If _TypeCharacterTable Is Nothing Then
            ... initialize table ...
        End If

        Return TypeCharacterTable(c)
    End Function
End Class

One thing my code above doesn’t do is consider multi-threaded situations. We’ll automatically generate thread-safe code for static local initializers, but since I have to do extra initialization above, I should really synchronize the initialization. One other thing to keep in mind is that static locals are only preserved per-instance in instance methods. Calling PrintNextNumber on two different instances of the containing type will not give sequential numbers. If the containing method is shared, however, the calling instance doesn’t matter.

Random factoid #1: Static locals are a major reason why we used the term “Shared” for shared members instead of “Static.” 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.

Random factoid #2: 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…

Panopticon Central’s greatest hits

2 Replies

One of the downsides of blogs is that good stuff tends to gradually scroll off into the sunset. Loyal readers may have caught all the good stuff over the past ten months, but newcomers may have missed some things entirely unless they were willing to wade through all of the other superfluous stuff. To make it easier to find useful information (at least, what I think is useful information), I’ve added some article categories to the panel on the right. The “Articles“ section contains general long-form items like “The Ten Rules of Performance“, while the “Personal FAQs“ and “VB FAQs“ section contain answers to frequently asked questions. I would have liked to just have headers that linked back to the original entries, but I couldn’t figure out how to do that in .Text, so I just pasted them into new articles with a link back to the original. If you want to comment on something, you’ll have to go back to the original entry and comment there. (I’m still working on a comments RSS feed so that comments on old entries can be tracked more easily.)

I still need to talk with Duncan about how this is going to mesh with the newly announced VB FAQ blog…

“Hello,” he lied.

1 Reply

I’m afraid I unintentionally lied to you all: I won’t be going on the VB 2004 World Tour after all. I had my ticket and everything, but I’m afraid something very urgent has come up at work and I’m not going to be able to go to Louisville and Chicago, which I am very bummed about. You’ll definitely still be getting Jay Schmelzer, though, who’s a terrific speaker so you won’t be going home empty handed. Jay’s also trying to line up someone to take my place, and I’m sure they’ll be great, too.

I apologize to all those people who are already lined up to get in to see me. Maybe you can head over to the movie theater and start getting in line for Episode III. I’m still hoping to get out on the Tour at some point, though, and those international destinations look pretty good to me!

VB’s 2004 (pseudo-) World Tour

6 Replies

As Robert and others have blogged about today, VB is doing a “World Tour” of user groups over the next several months. I added the quotes because at the moment all the dates are in the US, but it appears that international dates are also in the works. (I, for one, would love a chance to go back and visit Spain. Or Italy. Or England. Or, heck, anywhere!)

I’m going to be going to the Louisville, KY and Chicago, IL dates next week (4/20 and 4/21, respectively), so I hope to see some readers there! (See sidebar for a link to a full list of places/dates and registration links.)