to VB or Not to VB that is the question..

Hello all....

Well I must say I am a beginner in programming.... I tried to learn C++ (Ver6) but I just kept getting discouraged... But now that the internet has grown and there are more and more places to ask questions.. I have one for you....

after giving up hopes on teaching myself C++ i moved on to VB6... I gained enough knowledge to become dangerous but still not a guru...

Now with the addition of .net I fell like I am relearning everything all over again... So, my question to you is... Is this the time to dive right in and learn C# or should I stick to the basics.... (no pun intended).. What are the pros/cons.... and just how limited am I using VB?

Your input will help decide my future.. Thanks in Advance,

Anjari

your not limited at all
just use what ever language you want

Anything that can be done in C# can be done in VB without limitations??? such as compromising speed or functionality?


So if I wanted to make a high paced video game (Everquest for example) it can be done in VB just as well as C#?!?!?

I totaly under estimated VB then....

Thanks for the input..

Anjari

no u cant, the way C# compiles is slightly different, u get about 5% more speed and in c# u can use pointers and can't in vb..and u can do intelsense documentation in C# and vb can't...things like that...that make c# rule over vb

intelsense sounds neat but what is it :p

Anjari

intelsense is when u type

MessageBox.Show(

and it appears an yellow thing saying the sintax and saying what to type givin u info about the function u're using

I would not say that c# rules over vb. C# is also missing some important, at least to me, features. Example there is not with statement, wich can make you code significantly longer. Also vb is more intuative on some things, for example vb on a data row has a row property, c# you have to use the []'s to define an item. Also c# is much more picky, example you have to use the () and the end of a ToString, vb you don't. I would say that the only thing c# holds over vb is the use of pointers, but really who uses them anyways (they have a tendance to create more problems then they solve). And the intellisence thing is easly overcome in vb.

Don't get me wrong I tend to use c# now more than vb, a personal syntax prefernce, but I though I would just point out some other things.

Basically it all comes down to what syntax you like best.

Jeremy

I realize that this is probably an old post, but Intellisense does work in VB.NET.

I am by no means very good at it, but it does function. I believe you have to go to Tools->Options and set the proper VB.NET Environment options correctly.

I think you confusing what they mean by intellisense. they are not talking about the drop down when you hit a . after an object name. they are referring to the XML documentation available in C#,

Quote:

---

Originally posted by PT Exorcist
no u cant, the way C# compiles is slightly different, u get about 5% more speed and in c# u can use pointers and can't in vb..and u can do intelsense documentation in C# and vb can't...things like that...that make c# rule over vb

---

there is no speed difference

I would argue with the statement that there is no speed difference. I have used both c# and vb to process the same date, both written the same, and c# does seem to complete a little faster. But again unless you are dealing with a large amount of processing I don't think you are going to see a differnce, and even that that I don't think the differnce is enough to decide on one language rather than the other.

Please note that these observations are only a matter of my own experience and by no means deffently prove that one is/or isn't faster than another.

Jeremy

Ask anyone at MS and they'll tell you the same thing...there is "virtually" no performance difference at all!

Suprisingly there's actually one item in VB.NET that C# doesn't have that generates faster executing IL....the "With" statement ;)

This conversation happens all the time all over the place and as I've said many times before, it all boils down to how you like to write your code, those are the only major differences between the two. That, and the VS.NET IDE is greatly enhanced when using VB.NET over C#, but if you like the way the code looks in C# better, then you should use C#...it's all a visual and flow preference by the developer

Here's one convo I just participated in recently if you want some more reading

GotDotNet - Need Help With Languages (C# Vs. VB)

"Ask anyone at MS and they'll tell you the same thing...there is "virtually" no performance difference at all! "

What MS tells you and what the truth is sometimes doesnt jive! :D

But if you look at the IL code of a VB program, there are some extra references to the VisualBasic namespaces and I think this causes a slightly slower performance. Not really all that noticable to a human most of the time.

by "what MS will tell you" I meant, the working examples they have made and have available the source code for you to look at and do your own testing on ;)

As for referencing the Microsoft.VisualBasic Namespace, there are no performance implications with that...it's no different than referencing the System.Text Namespace or anything Namespace for that matter.

Heck, it's even possible to use the Microsoft.VisualBasic Namespace in C#. I've heard of people doing that so they can get the nice string functions like FormatCurrency, etc...so they don't have to write it themselves :p

But it is referenced in places it wouldnt need to be if it was C# code. Look at a VB app and a C# app that do the same exact thing sometime and see what I mean.

just make a search..some days ago a guy made a post somewhere here saying he worked for sometime in ms and that were actually some difference in the way c# works over vb

Quote:

---

Suprisingly there's actually one item in VB.NET that C# doesn't have that generates faster executing IL....the "With" statement

---

Show me the code you used to prove that!

From what I have learned, the compiler will just take your with statement and add in the full reference when it compiles. It just speeds up your programming a little, not the speed of the program. If this is wrong, show me how you came to your conclusions about it.

http://www.vbforums.com/showthread.p...hreadid=219247

I'm stealing techgnome's post and reposting it here.

Of course it is just one person's opinion.

in C# a object can't have more than a single interface?!?

Don't think so. I'm not sure, but I think it can have as many interfaces as it wants, as in any sane language.

as far as i know you can inherit 1 object, but you can implement as many interfaces as you want.

Yep,
That's right. And this was intentional. It screws up your design in inumerable ways to inherit from multiple classes. But, of course you can implement any sane number of interfaces.

...I love this thread! This same topic comes up every couple months or so. I would say if you love VB then program in VB. But, the time to learn .NET is not in the syntax anyways. It's understanding the framework and how to use it properly. (Although, personally I will never right a line of VB again if I have any say. I just get tired of all the extra typing.)

The only major oversight I see is the lack of XML documentation in VB. This really makes VB a second class language until Microsoft (or someone else) adds documentation support for it.

Read the following letter in the JAn 03 issue of .Net Magazine.
http://www.fawcette.com/dotnetmag/20...ments/letters/
IT may help.

Quote:

---

as far as i know you can inherit 1 object, but you can implement as many interfaces as you want.

---

Ah, that's what I thought. The same as in Java.

Another big plus for C# (in my opinion) is that projects like mono will concentrate on this language, as it is about to be standardized, as opposed to VB which will very possibly forever remain purely MS proprietary.

Scott, multiple inheritance was removed from Java as it was noticed that it is very sparely used in C++ except deriving from multiple purely abstract classes (=interfaces), so they removed it and replaced it with the interface implementation mechanism. I must admit that during my several years C++ experience I've yet to come across a situation where multiple inheritance offers any real advantages (though I expect I will at some point).
MS just copied all successful concepts of Java for their common language specification (interfaces, final/sealed classes, ...) and added things that people thought were missing (operator overloading, ...). I suppose that's the main reason why there is no multiple inheritance in .NET.

In effect it all comes down to personal preference. I learned programming with ; at line ends and {} to delimit blocks, with == being comparison and case sensitivity. I don't like VB. I don't even like Pascal, I'm a C syntax purist.
I know just enough VB to read code and to write an ActiveX test project, nothing more.

Quote:

---

Originally posted by hellswraith
Show me the code you used to prove that!

From what I have learned, the compiler will just take your with statement and add in the full reference when it compiles. It just speeds up your programming a little, not the speed of the program. If this is wrong, show me how you came to your conclusions about it.

---

I don't really have anything to show, but I'm sure if you search around long enough, you'll find it...

The With statement is for more than just making it less to type...check out these lines of code in VB

VB Code:

With something("blah").something("blah").blah
     'code that uses something inside of the blah property
End With

and these lines in C#

Code:

---

object temp = something["blah"].something["blah"].blah;
'code that uses something inside of the blah property

---

Those lines will both do the exact same thing and it's actually recommended that when accessing multiple items more than a few times, it is much more efficient to write your code that way, because it saves the time that it took to go and retrieve the property that you're actually going to be using for every single time you access it.

So by using the With statement, it makes it less to type AND saves access time to different methods and properties

But as you can see from the example, pretty much the exact same thing is doable in C#, it's just that it's not "built-in" so to speak.

Scott Penner, if you're using VS.NET, VB.NET actually requires less typing than C# ;) Now if you're not using VS.NET and using Notepad or whatever, then I could see your argument to typing, but hey, if you don't like to type, why are you programming? ;)

When coding in VB.NET, doesn't the IDE give you better intellisense than when coding in C#?

I really hate not having intellisese. I now need to see a list of available packages/namespaces, objects, data types, functions, etc... (In Java, since I wasn't using such a great IDE, I often wrote entire classes only to find out later that ones similar to them already existed).

i asked about that of multiply implementation of interfaces cuz the artictle someone posted there had a guy saying that C# can't use more than 1interface..!!!

Yes VB.NET has better intellisense.

agreed! the only two reasons I haven't switched from VB.NET to C# is the fact the IDE is better with VB.NET and I can read the code better, but if the IDE were just as good with C#, I would consider switching anyway :)

Quote:

---

object temp = something["blah"].something["blah"].blah;
'code that uses something inside of the blah property

---

It doesn't speed anything up. All your doing is creating a reference to the real object. This means the compiler now has to first go to the temp object, find where it references, then go to the original object. That definately won't speed up your app. It WILL shorten your typing.

VB.Net's With statement will shorten your typing, but won't improve performance.

9 times out of 10, i dont even use intellisense, i know what i want and how to get it, so i wouldn't choose a language based on the ide or intellisense.

Any proper compiler would use a register to do that automatically, but I'm not sure if the MSIL allows that.

hellswraith, it DOES help performance, .NET no longer has to access the objects before the one you're really after. Here, I'll totally spell it out.

this code is faster...

Code:

---

object temp = something["blah"].something["blah"].blah;
temp.yermom = whatever;
temp.whoha = blah;
temp.men = 1;
temp.women = 2;

---

than this code...

Code:

---

something["blah"].something["blah"].blah.yermom = whatever;
something["blah"].something["blah"].blah.whoha = blah;
something["blah"].something["blah"].blah.men = 1;
something["blah"].something["blah"].blah.women = 2;

---

some as simple as this, it won't really make a difference (not a noticable one anyway), but it will in larg loops and what not.

same thing goes for VB

this code is faster...

VB Code:

With something("blah").something("blah").blah
     .yermom = whatever
     .whoha = blah
     .men = 1
     .women = 2
End With

than this code...

VB Code:

something("blah").something("blah").blah.yermom = whatever
something("blah").something("blah").blah.whoha = blah
something("blah").something("blah").blah.men = 1
something("blah").something("blah").blah.women = 2

write the code out yourself and step through it...the first set of code in both example, will execute far less lines of code than the second two.

maybe i'm just not explaining myself well. i'll try to find an article at some point on this (it was actually proven by a C# programmer that i know that didn't believe me and thought the same thing about the with statement that you do)

OK, I understand what your saying now. Took me some time...lol...sorry. Your talking about refering to an object that is burried deep in other objects.

You would then be correct. This is because you don't have to reference the whole object hiearchy every time, you will just refer to that variable that points to the object itself, bypassing the hiearchy 'lookup' every time.

Sorry I didn't understand what you were refering to.

I was thinking you were using a temp reference so you didn't have to type as much when coding. Something like having an object named 'blahblahblahblah.SomeProperty', and making a temp variable as 'a.SomeProperty' just so you didn't have to type out the full name. That was what I was refering to.

why c# has worse IDE than vb.net?

Because the VB.NET IDE was just adjusted from the VB6 IDE and so the programmers could concentrate on adding features and smoothing things out.
The C# IDE could take a few things off the C++ IDE, but basically it had to be rewritten, thus making the time for extra features very short.
I supppose this will change with the next major release (.NET2, 8, whatever).

Quote:

---

Originally posted by kleptos
9 times out of 10, i dont even use intellisense, i know what i want and how to get it, so i wouldn't choose a language based on the ide or intellisense.

---

Well, good for you, but I find the intellisese to be a far better learning aid than some tutorial on the web, or some language reference book. I really have learned a lot more from being able to see and play with the objects and functions as I type than I ever could have by just reading my book (I've made a pretty cool Tetris-type game to help me learn, and it uses several objects and functions that aren't even documented in my book).

This is really interesting. Not that it would ever be enough motivation to switch back to VB, but the with thing does save quite a few steps in the IL. Here's an example that I tried to write identically in VB / C#. Following that is the disassembly for both. You will notice that VB is about 10 lines shorter...

VB

VB Code:

Sub Main()
        Dim MyHash As Hashtable = New Hashtable(10)
 
        MyHash.Add("TestKey", "TestValue")
 
        With CStr(MyHash("TestKey"))
            Console.WriteLine(.Length)
            Console.WriteLine(.ToString())
            Console.WriteLine(.GetHashCode())
        End With
 
    End Sub

C#

PHP Code:

---

static void Main(string[] args)
{
    Hashtable MyHash = new Hashtable(10);

    MyHash.Add("TestKey","TestValue");

    Console.WriteLine( ((string)MyHash["TestKey"]).Length );
    Console.WriteLine( ((string)MyHash["TestKey"]).ToString() );
    Console.WriteLine( ((string)MyHash["TestKey"]).GetHashCode() );
} 


---

VB IL

Code:

---

.method public static void  Main() cil managed
{
  .entrypoint
  .custom instance void [mscorlib]System.STAThreadAttribute::.ctor() = ( 01 00 00 00 )
  // Code size      83 (0x53)
  .maxstack  3
  .locals init ([0] class [mscorlib]System.Collections.Hashtable MyHash,
          [1] string _Vb_t_string_0)
  IL_0000:  nop
  IL_0001:  ldc.i4.s  10
  IL_0003:  newobj    instance void [mscorlib]System.Collections.Hashtable::.ctor(int32)
  IL_0008:  stloc.0
  IL_0009:  ldloc.0
  IL_000a:  ldstr      "TestKey"
  IL_000f:  ldstr      "TestValue"
  IL_0014:  callvirt  instance void [mscorlib]System.Collections.Hashtable::Add(object,
                                                                                object)
  IL_0019:  nop
  IL_001a:  ldloc.0
  IL_001b:  ldstr      "TestKey"
  IL_0020:  callvirt  instance object [mscorlib]System.Collections.Hashtable::get_Item(object)
  IL_0025:  call      string [Microsoft.VisualBasic]Microsoft.VisualBasic.CompilerServices.StringType::FromObject(object)
  IL_002a:  stloc.1
  IL_002b:  ldloc.1
  IL_002c:  callvirt  instance int32 [mscorlib]System.String::get_Length()
  IL_0031:  call      void [mscorlib]System.Console::WriteLine(int32)
  IL_0036:  nop
  IL_0037:  ldloc.1
  IL_0038:  callvirt  instance string [mscorlib]System.String::ToString()
  IL_003d:  call      void [mscorlib]System.Console::WriteLine(string)
  IL_0042:  nop
  IL_0043:  ldloc.1
  IL_0044:  callvirt  instance int32 [mscorlib]System.String::GetHashCode()
  IL_0049:  call      void [mscorlib]System.Console::WriteLine(int32)
  IL_004e:  nop
  IL_004f:  ldnull
  IL_0050:  stloc.1
  IL_0051:  nop
  IL_0052:  ret
} // end of method Module1::Main

---

C# IL

Code:

---

.method private hidebysig static void  Main(string[] args) cil managed
{
  .entrypoint
  .custom instance void [mscorlib]System.STAThreadAttribute::.ctor() = ( 01 00 00 00 )
  // Code size      103 (0x67)
  .maxstack  3
  .locals init ([0] class [mscorlib]System.Collections.Hashtable MyHash)
  IL_0000:  ldc.i4.s  10
  IL_0002:  newobj    instance void [mscorlib]System.Collections.Hashtable::.ctor(int32)
  IL_0007:  stloc.0
  IL_0008:  ldloc.0
  IL_0009:  ldstr      "TestKey"
  IL_000e:  ldstr      "TestValue"
  IL_0013:  callvirt  instance void [mscorlib]System.Collections.Hashtable::Add(object,
                                                                                object)
  IL_0018:  ldloc.0
  IL_0019:  ldstr      "TestKey"
  IL_001e:  callvirt  instance object [mscorlib]System.Collections.Hashtable::get_Item(object)
  IL_0023:  castclass  [mscorlib]System.String
  IL_0028:  callvirt  instance int32 [mscorlib]System.String::get_Length()
  IL_002d:  call      void [mscorlib]System.Console::WriteLine(int32)
  IL_0032:  ldloc.0
  IL_0033:  ldstr      "TestKey"
  IL_0038:  callvirt  instance object [mscorlib]System.Collections.Hashtable::get_Item(object)
  IL_003d:  castclass  [mscorlib]System.String
  IL_0042:  callvirt  instance string [mscorlib]System.String::ToString()
  IL_0047:  call      void [mscorlib]System.Console::WriteLine(string)
  IL_004c:  ldloc.0
  IL_004d:  ldstr      "TestKey"
  IL_0052:  callvirt  instance object [mscorlib]System.Collections.Hashtable::get_Item(object)
  IL_0057:  castclass  [mscorlib]System.String
  IL_005c:  callvirt  instance int32 [mscorlib]System.String::GetHashCode()
  IL_0061:  call      void [mscorlib]System.Console::WriteLine(int32)
  IL_0066:  ret
} // end of method Class1::Main

---

...interesting
(sorry for the long post :D )

Your test is not fair. As stated above the C# equivalent of a with block is a temporary reference:

Code:

---

static void Main(string[] args)
{
    Hashtable MyHash = new Hashtable(10);
    MyHash.Add("TestKey","TestValue");
    string t = (string)MyHash["TestKey"];
    Console.WriteLine(t.Length);
    Console.WriteLine(t);
    Console.WriteLine(t.GetHashCode());
}

---

Note that this syntax avoids the unnecessary ToString() call. And as I said a good compiler would even optimize the reference into a register. (In C you would use the register keyword but it doesn't exist in C# or VB.NET)

Yes, the With statment arguement confused me for a little bit also. I finally figured out what was being said. Just like CornedBee said, you can provide a temp reference to mimic the With feature of VB.