Difference between C# and VB.NET

  • Thread starter Thread starter Raj Dhrolia
  • Start date Start date
R

Raj Dhrolia

Hi Guys,

It might seem to be a very easy question, but i am very much eager to
know some good technical difference between C# and VB.NET.

Are there anything that i can do in one language and cannot in other?
And finally why C# seems to be a sort of standard in industry?

Regards,
Raj Dhrolia.
 
Hi Raj,
It might seem to be a very easy question, but i am very much eager to
know some good technical difference between C# and VB.NET.
Click to expand...

There is no technical difference only a language difference and some small
differences
- With C# there is a better posibility to make program documentation
- VB.net has a larger instruction set.
Are there anything that i can do in one language and cannot in other?
Click to expand...

Yes because it is a different language, but you can make with both the same
things.
And finally why C# seems to be a sort of standard in industry?
Click to expand...

C# and VB.net needs both the Net framework that only runs completly on W98+,
NT4 sp6+ and newer Window OS systems. There are activities with Mono on
Linux for both C# and VB.net

Here some links to see the differences between C# and VB.net

Code C# and VB
http://www.harding.edu/USER/fmccown/WWW/vbnet_csharp_comparison.html

Language compare
http://msdn.microsoft.com/library/en-us/vsintro7/html/vxgrfLanguageEquivalents.asp

I hope this helps a little bit?

Cor
 
Cor said:
Hi Raj,


There is no technical difference only a language difference and some small
differences
- With C# there is a better posibility to make program documentation
- VB.net has a larger instruction set.
Click to expand...

What about unsafe code in C# and VB.Net also doesn't support operator
overloading though they are planning on adding it
(http://blogs.gotdotnet.com/cambecc/permalink.aspx/5de5a161-9150-4237-a751-1
27195cceeab).
other?

Yes because it is a different language, but you can make with both the same

C# and VB.net needs both the Net framework that only runs completly on W98+,
NT4 sp6+ and newer Window OS systems. There are activities with Mono on
Linux for both C# and VB.net

Here some links to see the differences between C# and VB.net

Code C# and VB
http://www.harding.edu/USER/fmccown/WWW/vbnet_csharp_comparison.html

Language compare
http://msdn.microsoft.com/library/en-us/vsintro7/html/vxgrfLanguageEquivalents.asp

I hope this helps a little bit?

Cor
Click to expand...

Yves
 
Sure, Operator Overloading is not yet available in VB.NET, but will be
available in the next version. And you can't write unsafe code in VB.NET
(but who would want to do that anyway ;-). But there are some things VB.NET
has and C# doesn't: background compilation, more intelligent intellisense,
.... So yes: there are some things that can be done in C# and not in VB.NET,
and visa versa. But all the "important stuff" (like OO) can be done in both
languages.
 
Hi Phoenix,

Before there become misunderstandings, the code made with VB.net and C# is
the same.
(If you have in VB.net option strict on).

For unmanaged code you can use C++ but that is something else than C#

Cor
 
Cor said:
Hi Phoenix,

Before there become misunderstandings, the code made with VB.net and C# is
the same.
(If you have in VB.net option strict on).

For unmanaged code you can use C++ but that is something else than C#

Cor
Click to expand...

I'm talking about unsafe code, not unmanaged code.

It's not often used but a while back I needed to write some image
manipulation functions and without unsafe code they would take 10 times the
time to do the same job. With unsafe code however they get pretty close to
'old-fashioned' C/C++ code in execution time.

Yves
 
Although you can do it, programming Office apps is really ugly in C#,
mainly because it doesn't support optional arguments (which are
everywhere in VBA). There's also some really ugly late binding stuff,
particularly in Word, that's a PITA in C#. If you have to code Office,
you'll be happier using VB.NET.

-- Mary
MCW Technologies
http://www.mcwtech.com
 
I learned VB.NET but quickly moved to C# as most of the online samples,
code snippets, source code for books, etc. seems to be in C#. I am
programming mainly for smart devices using the compact framework and have
noticed that C# programs load faster and the exe sizes are smaller. It was
also fun learning C#.
I have been using VB since the first beta more than 12 years ago and it
was getting a little boring. The one nice thing about coding in VB using
Visual Studio is the code editor. That is about the only thing that I miss
from VB though...
 
I am
programming mainly for smart devices using the compact framework and have
noticed that C# programs load faster and the exe sizes are smaller.
Click to expand...

Could you give an example, because I don't think this is true... Both VB.NET
and C# code compiles to the same IL that is executed!
 
First off, its unlikely that any two compilers are going to result in the
same IL every time. Each compiler(even across versions for a given language)
may well chose different ways to achieve the same thing. For example, as
outlined in [1], the C# compiler chooses a different code path to load a
int64 than the vb one. The vb method is larger, but both will probably
result in similar(or equal) code upon JIT'ing.
The VB compiler also has a tendency to issue emit extra nop's for some
reason. I doubt it is important in the end(the JIT should clear that up),
but it can make larger executables. IIRC there is also a different default
alignment between the two, so in some cases the VB.NET compiler will result
in smaller code as well(C# should default to 4096, VB to 512).
Its really not too relevent, you should be able to throw up quick samples in
VB & C# and run them through ILDASM and see for yourself.

1. http://tinyurl.com/2h8gl
 
Ok, I agree the apps probably won't be EXACTLY the same size. But I don't
think the difference is as huge so that you notice it when starting the
application.

--
Greetz,
Jan
__________________________________
Read my weblog: http://weblogs.asp.net/jan
Daniel O'Connell said:
First off, its unlikely that any two compilers are going to result in the
same IL every time. Each compiler(even across versions for a given language)
may well chose different ways to achieve the same thing. For example, as
outlined in [1], the C# compiler chooses a different code path to load a
int64 than the vb one. The vb method is larger, but both will probably
result in similar(or equal) code upon JIT'ing.
The VB compiler also has a tendency to issue emit extra nop's for some
reason. I doubt it is important in the end(the JIT should clear that up),
but it can make larger executables. IIRC there is also a different default
alignment between the two, so in some cases the VB.NET compiler will result
in smaller code as well(C# should default to 4096, VB to 512).
Its really not too relevent, you should be able to throw up quick samples in
VB & C# and run them through ILDASM and see for yourself.

1. http://tinyurl.com/2h8gl
Jan Tielens said:
Could you give an example, because I don't think this is true... Both VB.NET
and C# code compiles to the same IL that is executed!

--
Greetz,
Jan
__________________________________
Read my weblog: http://weblogs.asp.net/jan
and
it eager
to
Click to expand...
Click to expand...
 
Hi Jan,
Ok, I agree the apps probably won't be EXACTLY the same size. But I don't
think the difference is as huge so that you notice it when starting the
application.
Click to expand...

What does it matters if VB.net is smaller

:-))

(I think it is not true and I think that there is no difference at all when
the same set of objects is used.)

I see both languages only as the glue to use with the big toolbox of
classes.

Cor
 
Jan Tielens said:
Ok, I agree the apps probably won't be EXACTLY the same size. But I don't
think the difference is as huge so that you notice it when starting the
application.
Click to expand...
It should only manifest if 1) the code from one is significantly harder to
JIT, 2) the exe size and working set is pushed up and forces odd paging, or
3) It results in a huge number of cache misses. None of these should happen
in the vast majority of cases, but there is a chance(granted, cache issues
may be caused by smaller code as well, its far beyond my capacity to figure
out). Such effects would likely be transient as well.
--
Greetz,
Jan
__________________________________
Read my weblog: http://weblogs.asp.net/jan
Daniel O'Connell said:
First off, its unlikely that any two compilers are going to result in the
same IL every time. Each compiler(even across versions for a given language)
may well chose different ways to achieve the same thing. For example, as
outlined in [1], the C# compiler chooses a different code path to load a
int64 than the vb one. The vb method is larger, but both will probably
result in similar(or equal) code upon JIT'ing.
The VB compiler also has a tendency to issue emit extra nop's for some
reason. I doubt it is important in the end(the JIT should clear that up),
but it can make larger executables. IIRC there is also a different default
alignment between the two, so in some cases the VB.NET compiler will result
in smaller code as well(C# should default to 4096, VB to 512).
Its really not too relevent, you should be able to throw up quick
Click to expand...
samples
in
VB & C# and run them through ILDASM and see for yourself.

1. http://tinyurl.com/2h8gl
It
was I
miss
Click to expand...
Click to expand...
 
So we all agree: there are some differences in size, but in 99.9% of the
cases these differences won't have any influence. Only in a very limited
number of cases either C# or VB.NET could have an advantage.

:-)

--
Greetz,
Jan
__________________________________
Read my weblog: http://weblogs.asp.net/jan
Daniel O'Connell said:
Jan Tielens said:
Ok, I agree the apps probably won't be EXACTLY the same size. But I don't
think the difference is as huge so that you notice it when starting the
application.
Click to expand...
It should only manifest if 1) the code from one is significantly harder to
JIT, 2) the exe size and working set is pushed up and forces odd paging, or
3) It results in a huge number of cache misses. None of these should happen
in the vast majority of cases, but there is a chance(granted, cache issues
may be caused by smaller code as well, its far beyond my capacity to figure
out). Such effects would likely be transient as well.
--
Greetz,
Jan
__________________________________
Read my weblog: http://weblogs.asp.net/jan
Daniel O'Connell said:
First off, its unlikely that any two compilers are going to result in the
same IL every time. Each compiler(even across versions for a given language)
may well chose different ways to achieve the same thing. For example, as
outlined in [1], the C# compiler chooses a different code path to load a
int64 than the vb one. The vb method is larger, but both will probably
result in similar(or equal) code upon JIT'ing.
The VB compiler also has a tendency to issue emit extra nop's for some
reason. I doubt it is important in the end(the JIT should clear that up),
but it can make larger executables. IIRC there is also a different default
alignment between the two, so in some cases the VB.NET compiler will result
in smaller code as well(C# should default to 4096, VB to 512).
Its really not too relevent, you should be able to throw up quick
Click to expand...
samples
in
VB & C# and run them through ILDASM and see for yourself.

1. http://tinyurl.com/2h8gl
I am
programming mainly for smart devices using the compact framework and
have
noticed that C# programs load faster and the exe sizes are smaller.

Could you give an example, because I don't think this is true... Both
VB.NET
and C# code compiles to the same IL that is executed!

--
Greetz,
Jan
__________________________________
Read my weblog: http://weblogs.asp.net/jan
"BGD" <[email protected]> schreef in bericht
I learned VB.NET but quickly moved to C# as most of the online
samples,
code snippets, source code for books, etc. seems to be in C#. I am
programming mainly for smart devices using the compact framework and
have
noticed that C# programs load faster and the exe sizes are
Click to expand...
Click to expand...
smaller.
It ago
and
Click to expand...
that
I
Click to expand...
Click to expand...
 
Hi Cor

I just hate discussions like "which language is better?". Being a VB6
developer, it was clear for me I better could start with VB.NET. And that
is, in my opinion, the only advantage VB.NET or C# can have. If you have a
VB6 backgroud, please start with VB.NET, if you have a Java (grin) or C++
background, please help yourself with C# (or managed C++). At a certain
point in time, you'll discover that you know both of them because you
understand the .NET way of doing stuff: application architecture is really
language independent!
 
Jan Tielens said:
Could you give an example, because I don't think this is true... Both VB.NET
and C# code compiles to the same IL that is executed!
Click to expand...

They don't. They both compile to IL, but not the same IL. For instance,
VB.NET puts in an extra bit of code in each catch block (IIRC) in order
to handle some stuff about LastError - I can't remember the exact
details. Another example came up a while ago on the CLR mailing list:
for some simple operation, the VB.NET compiler produced a version which
took fewer IL instructions, but more IL space in terms of bytes than
the C# version. If you were unlucky, that could have a significant
effect on performance as it could mean the difference between a method
being inlined or not.

By and large the performance of VB.NET and C# will usually be the same,
but that's not the same as them compiling to the same IL.
 
BGD said:
I have been using VB since the first beta more than 12 years ago and it
was getting a little boring. The one nice thing about coding in VB using
Visual Studio is the code editor. That is about the only thing that I miss
from VB though...
Click to expand...

In what way was VB "getting a little boring"? What causes the inability
to think up new challenges for oneself and the need to rely on Microsoft
for spoon-feeding one new challenges? Is it cretinism, or mere idiocy?
 
Back
Top