What can C# do that Visual Basic 6 can't?
C# can do quite a few things that Visual Basic can't. First of all, in Visual Basic, the two major kinds of projects created were desktop applications and some ActiveX code components. C# can create both of these kinds of applications and much more. In the .NET environment, there are four major classes of projects that can be created.
One class of project is the standard desktop applications that are very familiar to a Visual Basic developer. You can also use the same development environment to create Internet-based applications. These Internet applications fall into two major categories – a web type interface or a web service. This web service is probably one of the hottest topics in the computer business today, and is very easy to create with C#.
If you need to create middle tier type components, you will find that C# and .NET give you the ability to create class libraries.
In many cases, Visual Basic 6 developers use code components that were created in other languages, particularly C++. It was always very difficult to incorporate these code components in the Visual Basic 6 development environment. Because .NET has a variety of different languages that can be used to create assemblies, cross-language development with C# and .NET is now much easier than with Visual Basic 6.
In short, C#'s many new controls, its capacity for creating class libraries, and its functionality within the .NET environment makes all applications easy to create and reduces the time needed to create sophisticated applications.
Is a C# class comparable to a VB class module?
In a sense a C# class is comparable to a Visual Basic class, but there are also many differences between them. In Visual Basic, you could use class modules on occasion to solve very specific problems. In C#, class modules must be used for everything. Code must reside in a class module in C#.
In Visual Basic, you could often create code modules that housed publicly scoped functions that were called throughout an application. Since C# only uses classes, you now need to instantiate objects in order to get even basic function calls available to work in C#.
This problem is solved by a static method associated with the classes. You can now create classes in C# that have static methods associated with them, and these can be used in much the same way that you called public functions in Visual Basic 6.
The C# classes also support full inheritance, whereas Visual Basic 6 did not support inheritance. The code inside class modules is also slightly different. You always have to use parentheses when you pass parameters into a C# method, whereas in Visual Basic, it was often optional to use the parentheses. This is one of several minor syntactical changes.
In Visual Basic 6, one of the irritating syntactical properties was the optional use of the call statement. In some cases, using the call statement versus not using the call statement could change the behavior of the procedure you were calling, and how parameters were passed, and how return values were returned. The call statement cannot be used in C# because it doesn't exist.
In Visual Basic 6, by default, all parameters were passed into call procedures by reference. In C#, by default, all parameters are being passed by value.
In some cases, procedures that were written in Visual Basic depended upon return values coming back from those procedures through the parameters being passed by reference. If you do not specify that you want a parameter to be passed by reference in C#, it will be passed by value, and some of the routines may not work the way that you expect them to work.
Is there an equivalent type to the VB variant type in C#?
The Visual Basic variant type gave the ability to associate any number of kinds of values with the variable. In my opinion, I think it is a good decision to have eliminated this variant data type from the C# language. Although, it did give some flexibility, it also gave the user the license to create poor code.
In C#, the closest data type to the variant is called the object data type. Since Visual Basic 6 is not essentially an object-oriented programming language, and C# is, you will find that every object within the C# environment is derived from the class object, therefore it is the data type that will give you the flexibility to associate with many data types.
What is type safety in C#?
Before discussing type safety in C#, perhaps it would help to discuss what non-type safety is in Visual Basic.
In Visual Basic 6, you could have a parameter or a variable that was of type integer. You could then say that this variable was equal to the number 1, plus a string data type of 2. Visual Basic would coerce the string into a variable that would be able to add together, and then return the number 3. This type coercion was the source of many bugs that ended up in a Visual Basic program.
In C#, you cannot perform this type coercion automatically. If you want to transfer from one data type to another data type, you have to programmatically force that data type change. This is known as type safety. When you are working with an object that is expecting a specific data type and a parameter, or if you are working with a variable that expects a specific data type, you will get a compile time error if you do not give the data types exactly as they are expected. C# will notify you immediately that there is a problem.
How do you declare a property in C#?
The method of declaring a property in C# is quite different from the method used in Visual Basic. In Visual Basic, you would enter a class module and specifically put in two separate functions, one being a public property get, and the other being a public property let.
In C#, you declare the property with a one-line statement, and then you associate a code block with that one-line statement. Internal to that code block there will be two separate sections. One is a get section, which is associated with the accessor that will read the value of that property. The other section is a set section associated with that property, and this will be the piece of code that will be executed when anybody wants to write a value into the property.
What are the main differences between VB's error handling model and how C# handles errors?
There are major differences. In Visual Basic 6, you were accustomed to writing code that would say "on error go to" a particular label in your procedure. If there was an error, you could then go to that label, process the code, and then return to some location in the main body of your program. There was quite a bit of jumping back and forth.
In Visual Basic 6, raising errors was a way of finding bugs. In the C# environment, finding bugs is known as "throwing exceptions." These exceptions are objects that are created that are very specific to the type of error that is encountered.
Once you start writing a block of code that you think is susceptible to having runtime errors, you should put a try statement before that code. If any of those lines of code actually throw an exception, it will immediately drop down into the catch code block.
Once in the catch block, you can examine the exact kind of object that was thrown, determine the nature of the error, and then proceed with the code once you have identified the error. If all of the code executes successfully, you will drop out of the try …catch block.
Is debugging in C# like that in VB?
Debugging in C# is very similar to that in Visual Basic 6, with many enhancements. All of the debugging capabilities in C# come from a namespace. This namespace is System.Diagnostics.Debug. Once you enter this namespace, there are many features that can be used. In Visual Basic, you had the ability to set breakpoints, single step through your code, and send some information into your output window.
All of these capabilities are available to you in C#, but there are also many exciting new capabilities. In C#, if you have a series of breakpoints that are set in your application, they will be remembered if you close and then reopen your application. C# also grants the capability to temporarily disable some of your breakpoints.
You can also create conditional breakpoints. That is, execution will stop on the breakpoint only if a certain condition is met.
There are new capabilities for writing new information into the output window. Before, you could only use the debug.print statement. Now there are statements such as debug.WriteLine and debug.WriteLineIf – which allows you to write information to the output window on conditions.
Can you have parameterized constructors in C#?
One of the exciting features of the C# language is that it allows you to have parameterized constructors. In Visual Basic, you could write some code on the initialize event of an object. However, this initialize event could never accept any parameters, thereby limiting the functionality of the code that you could include in that initialize event.
In C#, you have an event that is the same name as the class itself. This qualifies that event as being the constructor for that object. You can pass parameters into that constructor, thereby giving more flexibility in the code that you write in the constructor event.
Not only can you pass parameters into the constructor, you can also have several different versions of parameter lists, the signature, and you can overload the constructors. So you may have a constructor in a class that in one case will accept an integer as a parameter. You may write another constructor for that same class that now accepts a string, and you may create a third version of that constructor that accepts both a string and an integer.
As long as the types of parameters and the numbers of parameters are different, C# will be able to distinguish one from another. This is a very powerful tool. It gives the user the ability to do parameterized constructors and the overloads of those constructors.
Do C# operators work in the same way as VB operators? For example, what is short-circuit evaluation?
In a sense, the C# operators do work the same as Visual Basics operators, but C# has a much larger set of operators that you can work with. The plus, minus, division, and multiplication operators behave the same in C# as they do in Visual Basic.
However, in C# we have a lot of extra operators to work with, such as ++ and --. So you can use I ++, which will automatically increment the value of I, or you can use J --, which will automatically decrement the value of the variable. These are operators that are not accessible to the Visual Basic programmer.
C# also gives us new operators – the += and the -=. You can use this operator in statements like the following:
I += 10
This is the same thing in Visual Basic as saying I is equal to I plus 10. It's a convenient short-hand notation.
C# also offers Simon operators and comparator operators. In Visual Basic, if you said A =B, you really weren't sure of what was happening outside that statement. Are you taking the value of B and assigning it into A, or are you simply comparing the value of A to the value of B? You had to study the rest of the code that surrounded that statement to figure out what it actually meant.
In C#, there are no ambiguities like this. If you are making an assignment where you want the value of A to be equal to the value of B, you say A = B. However, if you are simply trying to compare the two values, and you want a true or false value returned to let you know whether they are equal, you will say A == B. C# gives you a cleaner set of operators without any ambiguity.
Short-circuiting is going to be a major issue to Visual Basic developers and can be explained in this way. If you were creating a statement in Visual Basic 6 that stipulated that if the return value of function 1 was equal to true, and the return value of 2 was equal to true, then the program would continue to execute the code block.
If the return value from the first function is false, there's no hope that the return value of the second function is going to alter the overall expression. But in Visual Basic, you would go ahead and execute that function completely. If, by chance, function 2 wrote some information into a database, or altered a file structure, then so be it – the database would be changed or that file would be altered.
This is not the way it would work in C#. If function 1 returns a false, C# will not even execute function 2, knowing that there's no chance that the return value is going to alter the outcome. This can be quite difficult for Visual Basic programmers who are depending upon that second function to be called in all cases. This is known as short-circuiting.
Could you also talk about operator overloading?
Most Visual Basic programmers, whether they recognize the term or not, are already familiar with the concept of operator overloading. Let's say you have two strings in Visual Basic – one string called AB, and the other CD. If you add those two strings together with a plus sign, you get ABCD, a concatenation of the strings.
If you had two integers, 1 and 7, and you add those together, you get a value of 8, the sum of the integers. If you use the plus sign with a date on the left-hand side, and then a number like 3 on the right-hand side, you end up with that date plus three days. Now, obviously, the plus sign is doing something different in each case. This is known as operator overloading. The problem with this in Visual Basic 6 was that you could never use this feature on your own class modules.
In C#, you can have a class that has some data inside it. You can have another instance of that same class that has some other data. If it's appropriate, you can use the plus sign to add those two classes together and come up with yet a third instance of the class that may have some value inside of it that was based on the other two.
Operator overloading is a means for you to use the plus, the minus, and the equals sign, in a way that you see fit for the classes that you create on your own.
How does graphical functionality differ between VB and C#?
In Visual Basic 6, a lot of the graphical functionality was exposed as methods of the form itself, such as a line method or a circle method, and in many cases these methods were used to add to the visual appearance of the form. In C#, these equivalent functions are exposed out of a namespace called System.Drawing, so the functionality comes from a separate library as opposed to being associated with the form itself.
Does C# offer any new array management tools?
There are some exciting new array management tools in C#. The Visual Basic programmer was previously limited to working with either fixed size arrays, or working with arrays that could vary in size but which normally came at a tremendous performance penalty.
In C#, you have the ability to use fixed size arrays the way they have always been used. You now have new dynamic array lists that can be sized on the fly without any performance penalties.
Additionally, there are new objects, called the queue and the stack, which allow you to implement a first-in/first-out functionality, or a last-in/first-out functionality. These are both new tools that normally would have required a lot of work to implement in Visual Basic 6.
How are object initialize and terminate processes implemented in C#?
These initialize and terminate functions are called the constructor and the destructor. The constructor is used when the class is initialized, the destructor is used when the class dies or is returned to memory.
The initialize function is actually replaced by either a function or a series of functions that happen to have the exact same name as the class itself. These can be overloaded, and can be used for an entire family. So the major difference is that the initialize function in Visual Basic accepted no parameters, whereas you can now have many initialize functions inside your C# classes, with many varieties of different parameters.
The destructor warrants more discussion. The destructor in Visual Basic was created by using the terminate event, and the terminate event was very predictable as to when it would be fired. That is, when the object was destroyed, the code in the terminate event was fired.
In C#, the code that is in the terminate event will only fire when the object is actually destroyed. It will not fire when the object is marked for use by garbage collection. The destructor only behaves in one specific way in C#, and you have to pay very careful attention to when that code gets fired. It will not work until the garbage collector actually reclaims the resources of that object, and this may be at an unpredictable point in time.