What is allowed in Visual Basic that's prohibited in C# (or vice versa)?

Question

This is code-related as in what the compiler will allow you to do in one language, but not allow you to do in another language (e.g. optional parameters in VB don't exist in C#).

Please provide a code example with your answer, if possible. Thank you!

Answer 1

The semi-colon that ends up every line in C# is prohibited in VB, and that always makes me smile when I try going back to VB.Net...

Answer 2

VB and C# have different interpretations of what "protected" means.

Here's an explanation copied below:

The default constructor for WebControl is protected.

VB and C# have different interpretations of what "protected" means.

In VB, you can access a protected member of a class from any method in any type that derives from the class.

That is, VB allows this code to compile:

class Base
    protected m_x as integer
end class

class Derived1
    inherits Base
    public sub Foo(other as Base)
        other.m_x = 2
    end sub
end class

class Derived2
    inherits Base
end class

Because a "Derived1" is a base, it can access protected members of "other", which is also a base.

C# takes a different point of view. It doesn't allow the "sideways" access that VB does. It says that access to protected members can be made via "this" or any object of the same type as the class that contains the method.

Because "Foo" here is defined in "Derived1", C# will only allows "Foo" to access "Base" members from a "Derived1" instance. It's possible for "other" to be something that is not a "Derived1" (it could, for example, be a "Derived2"), and so it does not allow access to "m_x".

Answer 3

Off the top of my head (pre 4.0):

VB language "features" not supported in C#:

• Optional Parameters
• Late Binding
• Case insensativity

I'm sure there's more. Your question might get better answers if you ask for specific examples of where each language excels. VB is a currently better than C# when interacting with COM. This is because COM is much less of a headache when optional parameters are available, and when you don't have to bind to the (often unknown type) at compile time.

C# on the other hand, is preferable by many when writing complex logic because of its type safety (in that you can't bypass static typing) and its conciseness.

In the end, the languages are mostly equivalent, since they only differ on the fringes. Functionally, they are equally capable.

EDIT

To be clear, I'm not implying that VB doesn't allow static typing... simply that C# doesn't [yet] allow you to bypass static typing. This makes C# a more attractive candidate for certain types of architectures. In the 4.0 C# language spec, you can bypass static typing, but you do it by defining a block of dynamic code, not by declaring the entire file "not strict," which makes it more deliberate and targeted.

Answer 4

The new autoproperties in C# have not been done for VB.NET yet.

Answer 5

The volatile keyword is only available in C# http://www.devcity.net/Articles/160/5/article.aspx

Answer 6

In C# you have to assign your variable before you can use it. I think you can turn this off, but it's the default behavior.

So something like this:

int something;
if (something == 10)
{ ... }

Isn't allowed, but the VB equivalent would be.

Answer 7

I'm surprised that C#'s unsafe code has not been mentioned yet. This is not allowed in VB.NET.

Answer 8

VB.NET has support for CIL Exception Filters, C# doesn't:

Try 
  ...
Catch ex As SomeException When ex.SomeProperty = 1
  ...
End Try

Answer 9

In VB you can implement an interface with a method of any name - i.e. a method "Class.A" can implement interface method "Interface.B".

In C#, you would have to introduce an extra level of indirection to achieve this - an explicit interface implementation that calls "Class.A".

This is mainly noticeable when you want "Class.A" to be protected and/or virtual (explicit interface implementations are neither); if it was just "private" you'd probably just leave it as the explicit interface implementation.

C#:

interface IFoo {
    void B();
}
class Foo : IFoo { 
    void IFoo.B() {A();} // <====  extra method here
    protected virtual void A() {}
}

VB:

Interface IFoo
    Sub B()
End Interface
Class Foo
    Implements IFoo
    Protected Overridable Sub A() Implements IFoo.B
    End Sub
End Class

In the IL, VB does this mapping directly (which is fine; it is not necessary for an implementing method to share a name).

Answer 10

One of my favorites (and bummers)

In VB.Net you can struture a switch/case statement as such:

Select Case True

   Case User.Name = "Joe" And User.Role = "BigWig" And SecretTime = "HackerTime"
      GrantCredentials()

End Select

which allows you to evaluate some complex evaluations through a switch instead of a variety of if/else blocks. You cannot do this in C#.

Answer 11

Global variables don't exist in c# i think

Answer 12

The VB 9.0 compiler automatically translates literal XML into "functional construction" syntax. The C# compiler does not support this nice literal XML syntax.

Answer 13

VB allows nonvirtual calls to virtual instance methods (call in IL), whereas C# only allows virtual calls (callvirt in IL). Consider the following code:

Class Base
    Public Overridable Sub Foo()
        Console.WriteLine("Base")
    End Sub

    Public Sub InvokeFoo()
        Me.Foo()
        MyClass.Foo()
    End Sub
End Class

Class Derived : Inherits Base
    Public Overrides Sub Foo()
        Console.WriteLine("Derived")
    End Sub
End Class

Dim d As Base = New Derived()
d.InvokeFoo()

The output is:

Derived
Base

That's not possible in C# (without resorting to Reflection.Emit).

Answer 14

There were some useful articles in Visual Studio magazine back in Jan 2008.

• What C# developers should know about VB
• What VB developers should know about C#

Answer 15

Indexed properties are allowed in VB.NET, but not in C#

    Private m_MyItems As New Collection(Of String)
    Public Property MyItems(ByVal index As Integer) As String
        Get
            Return m_MyItems.Item(index)
        End Get
        Set(ByVal value As String)
            m_MyItems.Item(index) = value
        End Set
    End Property

Answer 16

VB has optional parameters on functions.

C# will only get these with C# 4.0

Answer 17

Handles and WithEvents keywords for automatic wiring of EventHandlers.

Private Sub btnOKClick(ByVal sender As Object, ByVal e As System.EventArgs) Handles btnOK.Click
End Sub

Answer 18

As Chris Dunaway mentioned, VB.NET has Modules which allow you to define functions and data.

VB.NET has the VB6 syntax for linking to methods in DLLs. For example:

Declare SetSuspendState Lib "powrprof" As Function (byval hibernate as Int32, byval forceCritical as Int32, byval disableWakeEvent) as Int32

(Although that actual declaration might have to be Marshalled)

---

Answer 19

In C# you can declare a property in an interface as having a 'get', and then implement it in a class with a get and set.

public interface IFoo {
  string Bar {get;}
}

public class Foo : IFoo {
  public string Bar {get; set;}
}

In VB, the equivalent to declating a property with a get would be to declare it ReadOnly. You can't then make the implementation writable.

Public Interface IFoo 

  ReadOnly Property Bar() As String

End Interface

Public Class Foo 
   Implements IFoo

  Public Property Bar() As String Implements IFoo.Bar  'Compile error here'

End Class

I find this to be a severe limitation of VB. Quite often I want to define an Interface that allows other code only to be able to read a property, but I need a public setter in the implemented class, for use by the persistor.

Answer 20

One of the overlooked or simply misunderstood features of the VB language is calling a function which has a ByRef parameter. Most languages support only a single method of passing parameters by reference: that is the scenarios directly supported by the CLR.

The CLR has a lot of restrictions on the type of values it supports for ByRef parameters and these restrictions get in the way of VB’s goal to be a flexible language. Hence the compiler goes to great lengths to be flexible and support multiple avenues of ByRef passing, much beyond what the CLR natively allows.

C# 4 now supports two versions of reference passing. In addition to the one available since 1.0 the ref modifier is now optional when making an interop call to a COM object.