VB vs C#

G

Guest

I first started with the C language using TurboC moving up to the full C++ with both borland/ms extensions. For the last couple of (dry) years, I have not needed to do full bore projects. As a result I switched to VB to make those quick util progs. Now that I am back into full(+1/2)-time coding, and using .NET now, I was wondering which direction would be better to take. I realise that I can create different 'modules' using either language and add them into a final project, but at the moment I am a one man team, so all the code will be mine. Which one is better for speed? and size? I've already noticed that VB.NET takes a lot of the drudgery out of code typing by auto-completing/formating a lot more than C# does, but C# provides a lot more control over events and interfaces. Does anyone have any thoughts or facts to put forward? I am interested in hearing what side other people have chosen and the reasons for it.
 
K

Klaus H. Probst

The differences are not relevant enough to matter. C# is *marginally* faster
in some instances because the compiler produces a bit more efficient IL. It
also has some features that VB# lacks, such as unsafe blocks and so on. On
the other hand, as you point out, VB# has some nicer coding aides.

If you're writing the average business app it should come down to using
whatever language you feel comfortable with.


--
____________________
Klaus H. Probst, MVP
http://www.vbbox.com/


Gary K said:
I first started with the C language using TurboC moving up to the full C++
with both borland/ms extensions. For the last couple of (dry) years, I have
not needed to do full bore projects. As a result I switched to VB to make
those quick util progs. Now that I am back into full(+1/2)-time coding, and
using .NET now, I was wondering which direction would be better to take. I
realise that I can create different 'modules' using either language and add
them into a final project, but at the moment I am a one man team, so all the
code will be mine. Which one is better for speed? and size? I've already
noticed that VB.NET takes a lot of the drudgery out of code typing by
auto-completing/formating a lot more than C# does, but C# provides a lot
more control over events and interfaces. Does anyone have any thoughts or
facts to put forward? I am interested in hearing what side other people have
chosen and the reasons for it.
 
C

Cor Ligthert

Hi Klaus,

New here?
The differences are not relevant enough to matter. C# is *marginally* faster
in some instances because the compiler produces a bit more efficient IL.

There are situations where VB is *marginally* faster because it can use the
Microsoft.Visual basic namespace which contents a few functions which have
more performance than the single Net namespace.

However the most regulars in the dotnet newsgroups languages.vb and
languages.csharp say only that it is a matter of preference which language
you choose, both languages have (for vb with option strict on of course) the
same performance.

Cor
 
J

Jon Skeet [C# MVP]

Cor Ligthert said:
There are situations where VB is *marginally* faster because it can use the
Microsoft.Visual basic namespace which contents a few functions which have
more performance than the single Net namespace.

A C# developer can use the Microsoft.VisualBasic namespace if they
really want to. I don't remember seeing any examples where it's faster
than can be achieved by not using it, however.
However the most regulars in the dotnet newsgroups languages.vb and
languages.csharp say only that it is a matter of preference which language
you choose, both languages have (for vb with option strict on of course) the
same performance.

Well, very similar performance, at least.
 
C

Cor Ligthert

Hi Jon,
A C# developer can use the Microsoft.VisualBasic namespace if they
really want to. I don't remember seeing any examples where it's faster
than can be achieved by not using it, however.

We did some test now already again a some long time ago in the language.vb
group (I did although with comments and test from the others as Jay B.).

The Find from a string is twice as fast as the indexOf method with a string.
I was also supprissed because I have no real VB classic background, so I
never use that (still not), as I often told you I think that the 1 as start
of an index is the best however, I am used to the zero to start an index.

The indexOff however outclassed the Find when it is with a real defined char
at least 10 times in performance (the char Find does not exist).

Not so long ago I did also test with the Replace and was expecting the same
result. However that MB find had the same speed as the Regex. The
string.replace was amazing enough the fastest with the stringbuilder.replace
(that is the one I like) on a very good second place (only a slight
difference). The test are done by more persons on more places in the world
on different computers and the methode is checked also by those persons.

The MB replace and the Regex was 10 to 100 times slower dependable on the
situation 1000 times a short string or 10 times a long string than the
string.replace. (It was a very simple Regex).

I hope this gives you some idea's

Cor
 
J

Jon Skeet [C# MVP]

Cor Ligthert said:
We did some test now already again a some long time ago in the language.vb
group (I did although with comments and test from the others as Jay B.).

The Find from a string is twice as fast as the indexOf method with a string.

I'd be interested to see that thread/benchmark. Do you remember what it
was called?

It's certainly possible that String.IndexOf hasn't been well-optimised,
but I suspect the optimisation could be done just as well in a C#
method if necessary.
I was also supprissed because I have no real VB classic background, so I
never use that (still not), as I often told you I think that the 1 as start
of an index is the best however, I am used to the zero to start an index.

Not sure how that's relevant here...
The indexOff however outclassed the Find when it is with a real defined char
at least 10 times in performance (the char Find does not exist).

Not so long ago I did also test with the Replace and was expecting the same
result. However that MB find had the same speed as the Regex. The
string.replace was amazing enough the fastest with the stringbuilder.replace
(that is the one I like) on a very good second place (only a slight
difference). The test are done by more persons on more places in the world
on different computers and the methode is checked also by those persons.

Why is it amazing that String.Replace is fast?
The MB replace and the Regex was 10 to 100 times slower dependable on the
situation 1000 times a short string or 10 times a long string than the
string.replace. (It was a very simple Regex).

I hope this gives you some idea's

I'm not at all surprised that Regex was fairly slow. People always seem
to be recommending that one should use a regex when it's just as simple
(and more readable) to use a few string operations.

Regular expressions are incredibly powerful, but most of the time that
power isn't needed.
 
C

Cor Ligthert

Hi Jon,
I'd be interested to see that thread/benchmark. Do you remember what it
was called?

It can get it using Google however showing the thread there is so much not
to the point in it, I do not want to show it to you, I pasted the test in
bellow (The Jon was another Jon with which it started, there are also some
crapy thing in like the one I call Cor stupid, that was because there where
so many solutions I said for fun you can use the split also, and than they
started to believe that and I had to show that it was not a good idea).
Although the methode from Jon was the fastest.
Not sure how that's relevant here...

To show you that I was suprized too.
Why is it amazing that String.Replace is fast?

It is not that the String.Replace is fast, I found it amazing that the
immutable String.replace was faster.
Regular expressions are incredibly powerful, but most of the time that
power isn't needed.

Same idea.

Cor

\\\
Private Sub Button1_Click(ByVal sender _
As Object, ByVal e As System.EventArgs) Handles Button1.Click
If Me.TextBox1.Text = "" Then
Me.label1.Text = "Enter strings in uper textbox"
Exit Sub
End If
If Not IsNumeric(Me.TextBox2.Text) Then
Me.label1.Text = "Enter value in down textbox"
Exit Sub
End If
TestString.Build(Me.TextBox1.Text.ToString, CInt(Me.TextBox2.Text))
Dim delimiter As String
If TestString.StringToTest.Length > 3 Then
delimiter = TestString.StringToTest.Substring(0, 3)
Else
Exit Sub
End If
Dim i As Integer
Dim labeltext As New System.Text.StringBuilder
Dim count As Integer
Dim testname As String
For i = 1 To 3
Dim StartTick As Integer = Environment.TickCount
Select Case i
Case 1
testname = "Jay B, string "
count = Test1(TestString.StringToTest, delimiter)
Case 2
testname = "Jon, string "
count = Test2(TestString.StringToTest, delimiter)
Case 3
testname = "Jon, but with indexof"
count = Test3(TestString.StringToTest, delimiter)
End Select
Dim Elapsed As Integer = Environment.TickCount - StartTick
labeltext.Append(testname & "count: " & _
count & " Elapsed : " & Elapsed.ToString & vbCrLf)
Next
delimiter = delimiter.Substring(0, 1)
labeltext.Append("characters" & vbCrLf)
For i = 1 To 6
Dim StartTick As Integer = Environment.TickCount
Select Case i
Case 1
testname = "Jay B, string "
count = Test1(TestString.StringToTest, delimiter)
Case 2
testname = "Jon, string "
count = Test2(TestString.StringToTest, delimiter)
Case 3
testname = "Jon, but with indexof "
count = Test3(TestString.StringToTest, delimiter)
Case 4
If TestString.StringToTest.Length < 599999 Then
testname = "Cor stupid "
count = Test4(TestString.StringToTest, delimiter)
Else
testname = "Skipped test"
End If
Case 5
testname = "Jay B char do until "
count = test5(TestString.StringToTest, delimiter)
Case 6
testname = "Jay B char for each "
count = test6(TestString.StringToTest, delimiter)
End Select
Dim Elapsed As Integer = Environment.TickCount - StartTick
labeltext.Append(testname & "count: " & _
count & " Elapsed : " & Elapsed.ToString & vbCrLf)
Next
Me.label1.Text = labeltext.ToString

End Sub
Private Sub Form1_Load(ByVal sender As Object, ByVal _
e As System.EventArgs) Handles MyBase.Load
Me.Button1.Text = "start test"
End Sub
Public Function Test1(ByVal input As String, ByVal delimiter _
As String) As Integer 'Jay B 1(string)
Dim count, index As Integer
index = input.IndexOf(delimiter)
Do Until index < 0
count += 1
index = input.IndexOf(delimiter, index + 1)
Loop
Return count
End Function
Public Function Test2(ByVal strInput As String, ByVal strDelimiter _
As String) As Int32 'Jon (string)
Dim iStart As Int32, iCount As Int32, iResult As Int32
iStart = 1
iCount = 0
Do
iResult = InStr(iStart, strInput, strDelimiter)
If iResult = 0 Then Exit Do
iCount += 1
iStart = iResult + 1
Loop
Return iCount
End Function
Public Function Test3(ByVal input As String, ByVal delimiter _
As String) As Integer 'Jon with indexof(x,x,x)
Dim iStart As Int32, iCount As Int32, iResult As Int32
iStart = 0
iCount = 0
Do
iResult = input.IndexOf(delimiter, iStart)
If iResult = -1 Then Exit Do
iCount += 1
iStart = iResult + 1
Loop
Return iCount
End Function
Public Function Test4(ByVal input As String, ByVal delimiter _
As String) As Integer 'Cor stupid
Dim teststring As String() = Split(input, delimiter)
Return teststring.Length - 1
End Function
Public Function test5(ByVal input As String, ByVal _
delimiter As Char) As Integer 'Jay 1(char)
Dim count, index As Integer
index = input.IndexOf(delimiter)
Do Until index < 0
count += 1
index = input.IndexOf(delimiter, index + 1)
Loop
Return count
End Function
Public Shared Function test6(ByVal input As String, _
ByVal delimiter As Char) As Integer 'JayB 2(char)
Dim count As Integer
For Each ch As Char In input
If ch = delimiter Then
count += 1
End If
Next ch
Return count
End Function
End Class
Public Class TestString
Private Shared mStringTest As String
Public Shared ReadOnly Property StringToTest() As String
Get
Return mStringTest
End Get
End Property
Public Shared Sub Build(ByVal strToTest As String, ByVal x As Integer)
Dim strTest As New System.Text.StringBuilder
Dim strTextbox As String() = Split(strToTest, vbCrLf)
Do While strTest.ToString.Length < x
Dim i As Integer
For i = 0 To strTextbox.Length - 1
Dim y As Integer
For y = 0 To i
If strTest.ToString.Length < x / 2 Then
strTest.Append(strTest.ToString & strTextbox(i))
Else
strTest.Append(strTest.ToString.Substring(0, x / 2) _
& strTextbox(i))
End If

Next
Next
Loop
mStringTest = strTest.ToString.Substring(0, x)
End Sub
End Class
 
J

Jon Skeet [C# MVP]

Cor Ligthert said:
It can get it using Google however showing the thread there is so much not
to the point in it, I do not want to show it to you, I pasted the test in
bellow

Thanks very much.

It is not that the String.Replace is fast, I found it amazing that the
immutable String.replace was faster.

Why? It's not like it'll be doing creating lots of extra strings.
Indeed, the fact that it's immutable may well be one of the reasons it
*is* faster - it doesn't need to be as careful about other threads
changing the contents during the operation.

Now, about the test itself - could you say what string you were
actually testing with (or rather, how to generate it)? I'd like to try
to reproduce this myself...
 
C

Cor Ligthert

Now, about the test itself - could you say what string you were
actually testing with (or rather, how to generate it)? I'd like to try
to reproduce this myself...

As far as I know I used a lot of strings as far as I remember it me there is
a stringbuilder in it which can make a real long but changing string.

We had a lot of fun it that time when this was made in the VB. newsgroup.

And with this it was was that we had said that I would make a testprogram
and Herfried should type in a string from 1 Mb, however he never did. And
he has heard that much times after that.

Cor
 
C

cody

On the other hand, as you point out, VB# has some nicer coding aides.


Choosing a programming language depending on the features of the IDE is a
very stupid idea since IDE's are changing quickly, the language doesn't.
 
C

cody

Does anyone have any thoughts or facts to put forward? I am
interested in hearing what side other people have chosen and the reasons
for it.

C# is much cleaner than VB, C# is much more OO than VB. C# is written
especially for .NET, there were not backward compatibiliy issues, C# has
better typechecking than VB, C# is faster than VB, C# supports lots of
features that VB doesn't have (unsafe code, using blocks), VB is only there
for backward compatibility and for VB coder who don't want to learn a new
language.
 
C

Cor Ligthert

Hi Cody,

I have nothing against C#

However there is a lot backwards compatibility in C# too

- suporting upper and lower case words as different
- the need *always* to end a sentence with the semicolon
- the enclossing from a condition with parentheses

(Those kind of things exist also in VB.net you do not have to show them to
me)

Just my thougth

Cor
 
C

cody

I have nothing against C#
However there is a lot backward compatibility in C# too

- suporting upper and lower case words as different
- the need *always* to end a sentence with the semicolon
- the enclosing of a condition with parentheses

What does this have to do with backward compatibility?
These are good features, why should they drop them?

In tiny scripting languages maybe it can be good not to have to write
semicolons or not to distinguish between uppercase and lowercase identifiers
but in language designed to be used by real programmers, designed to write
big serious applications and not small scripts, these features are good
since
they make code easier to maintain.
 
C

Cor Ligthert

What does this have to do with backward compatibility?
These are good features, why should they drop them?

Yes you describe very good why those features stayed in VB.net.

However lowercase had to do with the impossibility in past to destict in a
fast way that an uppercase word was the same as a lowercase.

And now it is only backward compatability, whatever there is told about it.

My and probably your language uses 26 latin characters which can only have
an uppercase on the first position. However does not change in most
languages its meaning when written with an uppercase.

Cor
 
D

Daniel O'Connell [C# MVP]

Cor Ligthert said:
Yes you describe very good why those features stayed in VB.net.

However lowercase had to do with the impossibility in past to destict in a
fast way that an uppercase word was the same as a lowercase.

And now it is only backward compatability, whatever there is told about
it.
Thats not entirely true. Backward compatability suggests that it is there
only so old code can work. Case sensitivity is there because some people
prefer it. A feature that people like isn't a hack for compatibility, it is
a feature that people like, infact its a fundamental feature of a langauge.
I for one think that case insenstivity is one of the worst things about VB.
My and probably your language uses 26 latin characters which can only have
an uppercase on the first position. However does not change in most
languages its meaning when written with an uppercase.
Programming languages are generally English based. Because of this you
should consider casing, IMHO. But that is a preference thing, which is why
VB is case insensitive and C# isn't.
 
C

Cor Ligthert

Hi Daniel,

C was not the first language which was case sensitive all older languages
where, just because that the cardreader could not recognize the fact that an
upercase punching was the same as a lower case punching.

In the past it was very usual therefore only to write in upercase.

Some C programmers started to call it an advantage probably because they did
use the teletype to input there programs.

When you want to use those code in your newer programs, you cannot change
that.

And that is what in my opinion is backwards compatabillity.

However for newer languages which should not have to do with that, can
follow in my opinion the normal languages rules be used as in all languages
which uses Latin characters.

Cor
 
J

Jeremy Todd

C# is much cleaner than VB

That's a matter of personal preference. I find VB.NET code to be much
more readable than C#. If you're used to C/C++, I can understand how you
might prefer C# out of familiarity, but that's subjective opinion.
C# is much more OO than VB.

Can you clarify that? As far as I am aware, both languages support the
full set of CLR object features.
C# has better typechecking than VB

Again, in what way? Use Option Strict, and VB.NET's type checking is
every bit as rigorous as C#'s.
C# is faster than VB

For some things. For others, it's just the reverse. It all comes out
as MSIL in the end. As has been said 500 times on these newsgroups, there
is no significant performance difference between VB.NET and C#.
C# supports lots of features that VB doesn't have (unsafe code,
using blocks)

And VB.NET supports lots of features that C# doesn't have: better
interface implementation support (in VB.NET, any method with any scope and
name can implement one or more interface methods -- this is a HUGE plus for
me, and the primary reason I chose VB.NET over C#), With blocks, etc. There
are pros and cons to both languages.

Also, don't put too much emphasis on IDE features, but don't ignore them
either. Under VS.NET 2003, coding VB.NET is much easier and much less
error-prone than C#. Compiler errors are spotted in real time, and the
Intellisense support is much more thorough.

Jeremy
 
J

Jon Skeet [C# MVP]

Cor Ligthert said:
However for newer languages which should not have to do with that, can
follow in my opinion the normal languages rules be used as in all languages
which uses Latin characters.

Normal language is case-sensitive - at least modern ones tend to be. In
English start sentences and proper nouns with capital letters. German
starts nouns with capitals.

Reading various posts which ignore the rules of normal English has only
enforced my opinion that the sensible (and sensitive) use of case
enhances readability.
 

Ask a Question

Want to reply to this thread or ask your own question?

You'll need to choose a username for the site, which only take a couple of moments. After that, you can post your question and our members will help you out.

Ask a Question

Top