C# vs VB.NET. Facts not opinions please :)
-
I havent done a great deal of research into this but I have seen example code in VB.NET that goes something like:
Public Sub DoSomething(sender as Object, e as EventArgs) Handles Button1.Click, Button2.Click, MenuItem1.Click
and i really like this new "Handles" clause in defining events. What I havent seen is the same thing used in C#. I assume you can still use AddHandler and acheive the same thing, though I havent seen that either. I guess the first question is can you do either of these, but the real question I have is, aside from syntax, personal preference, or the stigma associated with one or the other, why should I choose C# over VB.NET? Are there things that one does that the other doesnt? Or that one does better, that the other doesnt? Christian, I notice you have gone straight to C# as your first .NET language. Is it based on anything other than the fact you are more used to typing/seeing braces rather than "End If"? -- David Wengier Sonork ID: 100.14177 - Ch00k
-
I havent done a great deal of research into this but I have seen example code in VB.NET that goes something like:
Public Sub DoSomething(sender as Object, e as EventArgs) Handles Button1.Click, Button2.Click, MenuItem1.Click
and i really like this new "Handles" clause in defining events. What I havent seen is the same thing used in C#. I assume you can still use AddHandler and acheive the same thing, though I havent seen that either. I guess the first question is can you do either of these, but the real question I have is, aside from syntax, personal preference, or the stigma associated with one or the other, why should I choose C# over VB.NET? Are there things that one does that the other doesnt? Or that one does better, that the other doesnt? Christian, I notice you have gone straight to C# as your first .NET language. Is it based on anything other than the fact you are more used to typing/seeing braces rather than "End If"? -- David Wengier Sonork ID: 100.14177 - Ch00k
To be honest, I went right for C# because a/ it's been marketed to me, b/ it's been presented as the ease of VB/the power of C++, c/ I have the resources here, and d/ (sorry, but) I'd be embarrased to choose VB unless I had compelling reasons I could argue for it. I've discovered tonight that you can use pointers in C#, although I'm not yet sure of the implications of using the unsafe keyword. It appears though that 'unsafe' is the only way I can use the BitmapData class as anything other than a hood ornament. The very existence of C# AND VB.NET AND Managed C++ to me means that we have two transitional languages to pull people into what M$ want us to develop CLR code in, and that is C#. I am not bailing no C++ at ALL (EVER), but I refuse to use Managed C++ unless a compelling reason arises, because it makes no sense to me to use it. If I want powerful native code, I go to C++, that's why I never learned VB. If I want CLR code, then I will go to C#. I know Managed C++ is optimised, but I think there is more advantage in using the language designed from the ground up with the task in mind. And in a night I've learned enough to write a program that loads and saves a bitmap, displays it in the dialog and offers an invert filter. Most of that time has been spent figuring out how to use BitmapData, by far, and the answer is in the good old fashoined pointer way, which I didn't realise was possible. As I say, I need now to find out if there are any repercussions of using it. Christian The tragedy of cyberspace - that so much can travel so far, and yet mean so little. "I'm thinking of getting married for companionship and so I have someone to cook and clean." - Martin Marvinski, 6/3/2002
-
To be honest, I went right for C# because a/ it's been marketed to me, b/ it's been presented as the ease of VB/the power of C++, c/ I have the resources here, and d/ (sorry, but) I'd be embarrased to choose VB unless I had compelling reasons I could argue for it. I've discovered tonight that you can use pointers in C#, although I'm not yet sure of the implications of using the unsafe keyword. It appears though that 'unsafe' is the only way I can use the BitmapData class as anything other than a hood ornament. The very existence of C# AND VB.NET AND Managed C++ to me means that we have two transitional languages to pull people into what M$ want us to develop CLR code in, and that is C#. I am not bailing no C++ at ALL (EVER), but I refuse to use Managed C++ unless a compelling reason arises, because it makes no sense to me to use it. If I want powerful native code, I go to C++, that's why I never learned VB. If I want CLR code, then I will go to C#. I know Managed C++ is optimised, but I think there is more advantage in using the language designed from the ground up with the task in mind. And in a night I've learned enough to write a program that loads and saves a bitmap, displays it in the dialog and offers an invert filter. Most of that time has been spent figuring out how to use BitmapData, by far, and the answer is in the good old fashoined pointer way, which I didn't realise was possible. As I say, I need now to find out if there are any repercussions of using it. Christian The tragedy of cyberspace - that so much can travel so far, and yet mean so little. "I'm thinking of getting married for companionship and so I have someone to cook and clean." - Martin Marvinski, 6/3/2002
Christian Graus wrote: I've discovered tonight that you can use pointers in C#, although I'm not yet sure of the implications of using the unsafe keyword. unsafe code does compile to IL, but it is unverifiable; so you need a higher permissions set to run the code. The same goes for P/Invoke. James Sonork ID: 100.11138 - Hasaki "Smile your little smile, take some tea with me awhile. And every day we'll turn another page. Behind our glass we'll sit and look at our ever-open book, One brown mouse sitting in a cage." "One Brown Mouse" from Heavy Horses, Jethro Tull 1978
-
I havent done a great deal of research into this but I have seen example code in VB.NET that goes something like:
Public Sub DoSomething(sender as Object, e as EventArgs) Handles Button1.Click, Button2.Click, MenuItem1.Click
and i really like this new "Handles" clause in defining events. What I havent seen is the same thing used in C#. I assume you can still use AddHandler and acheive the same thing, though I havent seen that either. I guess the first question is can you do either of these, but the real question I have is, aside from syntax, personal preference, or the stigma associated with one or the other, why should I choose C# over VB.NET? Are there things that one does that the other doesnt? Or that one does better, that the other doesnt? Christian, I notice you have gone straight to C# as your first .NET language. Is it based on anything other than the fact you are more used to typing/seeing braces rather than "End If"? -- David Wengier Sonork ID: 100.14177 - Ch00k
David Wengier wrote: I guess the first question is can you do either of these C# has overloaded the += and -= operators for events so that you can add and remove event handlers at runtime. This is also the only way that C# lets you add event handlers. The AddHandler statement that you see in VB is VB specific and is part of the VB.NET language. However if you can get access to the underlying EventHandlerList there is an AddHandler method on that you can use. An Events property of type EventHandlerList is exposed on the System.ComponentModel.Component class and its derivatives as well as the System.Web.UI.Control class. David Wengier wrote: Are there things that one does that the other doesnt? VB lets you assign events with the Handles keyword; it is also easier to do Late Binding with VB but you can accomplish the same with some Reflection in C# (or any .NET language). C# lets you overload operators, and create/use indexers (a property on a class so that you can treat an instance of the class like an array ie foo[3]). Someone on the DOTNET list noticed that the IL that VB.NET produces has a lot of NOPs in its code generation. While it makes the IL a little bit bigger the JIT will compile those away to nothing. HTH, James Sonork ID: 100.11138 - Hasaki "Smile your little smile, take some tea with me awhile. And every day we'll turn another page. Behind our glass we'll sit and look at our ever-open book, One brown mouse sitting in a cage." "One Brown Mouse" from Heavy Horses, Jethro Tull 1978