Visual CSharp .NET Developer's Handbook (2002) [eng]

Differences on the Surface

The first difference is that Visual C++ programmers are used to working in an unmanaged environment, while C# always relies on a managed environment. The differences between a managed and unmanaged environment are many. Using the managed environment implies working with the .NET framework, which means the compiler doesn't create native EXE files. Any application you develop with C# will have to run on a machine that has the .NET framework installed, because C# compiles to intermediate language (IL) code. This won't be much of a problem as more machines have the .NET framework installed, but it could be a problem today; many older machines won't have the required level of support installed.

Note Visual C++ .NET offers a managed environment as an option. However, many developers will likely continue using the unmanaged environment or a mixed environment for projects because of the large base of code available for Visual C++. In addition, using the unmanaged environment does provide certain benefits for the developer. For example, the developer, not the runtime environment, determines memory management policies.

Working with managed code also makes a difference to the developer. It enables you to concentrate on creating code, rather than managing memory. As mentioned in Chapter 1, one of the biggest problems that Visual C++ developers have is with memory management. Applications with memory leaks are problematic. C# answers this problem by managing the memory for you. That's what it means to provide a managed environment. Of course, developers will still require time to adjust to the new way of working with Windows.

The use of global variables is also a problem for many Visual C++ developers because global variables are at the heart of many Visual C++ projects. C# doesn't support global variables for good reason—the use of global variables leads to poor programming habits. In addition, consider that everything in C# is somehow related to an object. This means that everything must appear within a class—including variables. In short, C# enforces good programming habits and provides better object support than Visual C++ ever will.

One of the benefits of using C# is that it has no order of dependence. You don't have to make forward declarations of methods within the classes. In addition, the methods can appear in any order, and you can call them in any order. The lack of order dependence means that you can organize the code in the way that best suits your needs and personal tastes. If you want to place the code in alphabetical order, C# doesn't care and you won't suffer any kind of penalty for doing so.

A final surface difference is the fact that C# is a higher level language than Visual C++. It might look like Visual C++, but you don't have direct access to the hardware or the operating system. (While you can gain access to both hardware and operating system using PInvoke or Visual C++ wrapper code, the fact remains that you must do something special to gain this access.) Some Visual C++ developers find the loss of control over their environment difficult until they have worked with C# for a while. In some respects, this is the same transition that developers made when they moved from writing code in assembler to working with C.

Conceptual Differences

One of the major differences between C# and Visual C++ is conceptual. When you work with C#, everything is an object. Everything you use in C# ultimately derives from a base class named objects. This includes items that have some other basis in Visual C++, such as variables. In C#, you can box an integer and treat it as an object. You can manipulate it without calling on library routines. If you want to convert an integer into a string, you don't need to create a second variable and call upon itoa() to do it. The conversion process occurs with the integer and the methods associated with it.

Unlike Visual C++, C# has no need for a runtime library. Many developers are used to working with a combination of the runtime library and one of several APIs, such as the Win32 API. C# relies exclusively on the functionality provided by the .NET Framework. This lack of libraries means that you no longer need to worry about include files and that C# only needs to reference the centralized functionality of the .NET Framework.

The loss of libraries also means the loss of arcane return codes. When a C# application experiences an error, CLR raises and exception. The use of a try...catch statement ensures the C# application can handle the exception and possibly recover from it. The point is that errors always use the same reporting mechanism and you never have to worry about where to find error information. This feature makes the whole issue of error handling easier.

The whole idea of versioning is also new. Because CLR handles member layout based on the versioning information contained within the assembly, C# developers won't run into as many compatibility issues. If CLR can't find the correct version of a .NET Framework or other support assembly, it will provide an error message stating the problem and the application will fail to run. This solution might not provide the perfect world that developers hope for, but it's better than allowing a user to start an application that acts strangely because it lacks support from the correct DLLs (also known as DLL hell).

Properties are first-class citizens of C#. In Visual C++ a developer creates a property, but makes it private. A user accesses the property through accessor methods that change the value of the property. C# changes this by making the accessor methods a part of the property declaration. Every property can have a get and/or a set method. If you use get alone, the property is read-only. Using set alone means that the property is write-only.

An array in Visual C++ is a pointer to a sequence of data elements. In C# an array is an object. This difference between array implementations means that arrays can provide more functionality in C#. For example, you can't write past the end of an array in C# because CLR will raise a bound error. Arrays also come in single dimensional, multi-dimensional, and ragged (or jagged) varieties.

In general, you'll find that C# supports both synchronous and asynchronous operations on most objects that handle data. The use of object methods determines whether the action is synchronous or asynchronous. For example, if you want to perform a synchronous write to a file, you would use the Write() method. On the other hand, if you want to perform an asynchronous write, you would begin the action with BeginWrite() and end it with EndWrite().

New Statements

The statements that will cause developers the most trouble are those that have equivalents in Visual C++. For example, many developers rely on fall-through behavior for the switch statement. A switch statement in C# has no fall-through behavior. Every case must end with either a break or a goto. Of course, the goto statement has had a less than stellar history, so some developers will approach it caution. However, if you want to implement a fall-through behavior, you must do it explicitly using a goto.

Some statement differences will come as a relief to Visual C++ developers who've spent many hours scratching their heads over a problem. For example, the foreach statement is simple in concept, yet Visual C++ never had it (and doesn't have it in the latest release). The foreach statement reduces coding requirements by helping the developer work with enumerated data. For example, you could use the foreach statement to parse the contents of the drives on a network without writing complex code to do it.

Visual C++ developers share some new features with C# developers. For example, attributes are a new feature that both categories of developer can enjoy. However, even in this arena you can see differences between the world of Visual C++ and C#. Visual C++ developers will use attributes as a matter of convenience. After all, for a Visual C++ developer, attributes simple replace code that the developer would have written anyway. A C# developer needs attributes to work effectively with the .NET platform. Not only do attributes provide a means for writing boilerplate code quickly, but they also provide a means for performing tasks such as documenting code behavior. You also use attributes to perform tasks such as including declarative security within your application.

Note Attributes are an extremely useful feature in C#. We discussed how to create your own custom attributes in Chapter 6. See the Attribute example in that chapter for details. In some cases, you must use attributes to accomplish specific security goals. We discussed the use of declarative security in Chapter 9. Make sure you look at the declarative programming example in that chapter, because it shows the mandatory use of attributes for security purposes.

The checked and unchecked keywords provide for additional math function validation not found in Visual C++. When a math operation is checked, CLR verifies that the operating doesn't result in an overflow. If an overflow does occur, the application will generate an exception that the code must handle. Using unchecked means that CLR won't check for overflows, but that the results of math operations are also less certain that that you might experience unpredictable results.

C# provides the concept of an indexer, which is essentially a specialized form of an array. The indexer is a means of addressing a particular element of a collection—an array of objects. You'll use this particular feature regularly with the foreach statement. For example, if you wanted to poll the device drivers supported by the system, you'd first gain access to a system object and then use an indexer to list each device object individually. Note that an object must support the IEnumerable interface before the foreach statement will work with it. The concept of an enumerator is also new to C#.

Working with Objects

It's important to note that C# has a distinct method for working with objects. Of course, you need to differentiate first between an object and a value. Objects always rely on references to memory allocated from the heap, while values always appear directly on the stack. C# makes it easy to turn any value into an object using the concept of boxing, but you can only unbox objects as specific value types.

You'll also find that C# supports only single inheritance, while Visual C++ supports multiple inheritance. All objects ultimately derive from a base class named object and can only inherit from a single base class derived from object. However, C# classes can implement multiple interfaces. (See the "Creating Interfaces" section of Chapter 3 for details on creating and working with interfaces.) Whenever an object uses an interface it must implement the methods within the interface, but it also derives the benefit of the structure the interface provides. Needless to say, C# doesn't provide support for templates, making some of the benefits (and the problems) of templates a thing of the past.

Note There were rumors that Microsoft would add template support to C# sometime in the future. Unfortunately, Microsoft isn't saying much about template support at the time of this writing, so it's hard to tell if this feature will ever appear in C#. Even if Microsoft (or ECMA) adds template support, the support is unlikely to match the type of template support provided in Visual C++. In addition, the use of templates would require the addition of generics to the .NET Framework, a problematic addition at best, and an impossible one at worst.

C# had a distinct meaning for the new keyword. When you use new, you're requesting a new copy of an object. The compiler creates the object and calls its constructor with any arguments you provide. In short, the object is ready to use after you create it. In addition, the object has a definite value before you use it for the first time. Of course, you might need to provide additional information before the object will actually do something useful.

For Those Who Work with Both Languages

Even after you consider all of these differences, some people might be tempted to say that Visual C++ and C# share more than they differ. The fact is that you can't use Visual C++ one day and immediately begin using C# the next. Developers will need time to overcome old habits. For example, one of the nicer features that I'm getting used to is not worrying about header files all the time. You can write C# applications using a single file if desired.

Tip The differences between C# and other languages has become a major topic of discussion for many people. The existence of a new language intrigues many people enough that they'll spend hours in detailed comparisons. You can benefit from their researches. One of the better-detailed comparisons of C# with other languages is at http://genamics.com/developer/csharp_comparative.htm. The author provides detailed comparisons of C# with other languages at 26 different levels, including date types, versioning, and interoperability. Another good place to look for comparisons is http://www.softsteel.co.uk/tutorials/cSharp/lesson2.html. This site takes a tutorial approach and discusses the differences one language at a time.

If you're like me and work with a variety of coding projects, you'll likely find that you need to keep both your Visual C++ and your C# skills current. Sometimes that means working on a project like the security example in Chapter 9 where you use both languages in the same project. Moving back and forth between languages in that project really kept me on my toes and helped reinforce the differences between the two languages. In many cases, this technique is the one that will help you learn C# in the fastest way possible—constant exposure to the differences between the two languages tends to reinforce the advantages and disadvantages of each language in your mind.

Language Gotchas for Visual C++ Developers

Working with any new language requires a lot of flexibility. Developers, like anyone else, get into a rut—they learn to do things a certain way, so anything new proves difficult. Of course, becoming proficient at coding means learning the techniques well enough that you can write code in your sleep. In short, the developmental rut is a requirement for efficient programming. However, a developmental rut is also the best way to run afoul of new programming language features. With this in mind, the following list tells you about programming features that developers seem to use improperly most often when moving from Visual C++ to C#.

Note I'd like to make an effort to keep this list current. If you have a particular problem with the move from Visual C++ to C# and would like to share it, please feel free to write me at JMueller@mwt.net. Significant problems experienced by more than one reader could also appear in my Pinnacle newsletter, .NET Tips, Trends & Technology eNewsletter (http://www.pinnaclepublishing.com). I plan to provide an update to this list on my website at http://www.mwt.net/~jmueller/. Check my website for further details.

Using Struct A difference that will almost certainly trap some Visual C++ developers making the move to C# is the struct. In Visual C++, a struct is functionally the same as a class. In fact, C++ uses structs as lightweight classes. In C#, a struct is a means for passing data from one place to another and nothing more. Yes, a struct can still contain code in C#, but the whole concept of the struct is different from Visual C++. If you want to create code, then you need to create a class. The best way to look at a struct in C# is as a complex value allocated on the stack—classes are references allocated on the heap. Struct also has limitations not found with classes. For example, you can't derive from a struct and a struct can't use any base class except those found in System.ValueType.

Tip Structs are limited compared to classes in C#. However, structs are also more efficient than classes, because they don't have the overhead associated with heap allocation. Careful use of structs in your application can increase performance and reduce memory requirements.

Using Bool Sometimes, the little things count the most. Consider the Boolean value. In Visual C++, you can use an integer as a replacement for a bool. In C#, however, you must use a bool at all times. This means that if you use an int, it must end as a bool. For example, you'd need to write for (!MyInt) as for (MyInt != 0). Many Visual C++ developers will have to break habits they learned while working with Visual C++ before they can effectively work with C#, and it will be due to these small differences.

Understanding Non-deterministic Finite Automation (NFA) The managed environment provided by C# caused one problem that most Visual C++ developers notice right away. Most

C# classes don't have destructors. It's not that a developer can't add a destructor to a class; it's that the developer never knows when the Garbage Collector will call the destructor. This lack of control over the calling of the destructor is called Non-deterministic Finite Automation (NFA). This relatively complex term describes an equally problematic situation for the developer. It means that the developer must now find a way to ensure the class will work as intended without relying on the destructor to perform any required cleanup. Given the way C# and CLR works, the problem is actually less than you might think—consider that there's no need to release memory because the Garbage Collector takes care of the problem for you.

Overcoming the Lack of macro support Many Visual C++ developers live on macros when coding their applications. While C# does support a preprocessor for conditional code, you won't find any support for macros. This means the developer must rethink some ways of writing code and that some operations might not be possible (at least not possible in the same way they were in Visual C++). The lack of macros tends to make code easier to understand, but also means that some of the shortcuts that Visual C++ developers used in the past are gone.

Overcoming the lack of Typedef support A Typedef in Visual C++ gives an existing type a new name that better describes the function of the type within the code. The Typedef doesn't actually create a new type, it simply renames the existing type. When used properly, a Typedef can make code more readable. Unfortunately, the use of Typedef more often confuses anyone attempting to read the code. C# doesn't support Typedef, which means any inadvertent renaming of variable types the developer performs will cause errors during compilation. While the compiler does catch this particular error, it's still inconvenient and many developers will do it almost as a reflex action.

Understanding language oddities There are many changes that fall into the nuisance category. While the compiler will catch any error you make in this area, the source of the problem isn't always clear. For example, you must capitalize the Main() method for your application (unlike Visual C++, which uses lowercase). You also won't require a semicolon after a class declaration. If you add one, the C# compiler will identify an error, but not necessarily the correct error, which means checking the code line-by-line until you locate the errant semicolon.

Understanding the definite assignment requirement Normally, when you create an object in C#, you'll use new to create a new copy of the object. However, C# doesn't require that you create a new object—you can also assign an existing object to a new object. C# does require that you make some type of assignment to every object before you use it, so you must either use the new keyword to create a new copy of an object or assign an existing object. Any other action will result in errors.

It's important to realize this list contains the most common gotchas for developers moving from Visual C++ to C#. However, it doesn't include your personal list of learning curve problems. There are many ways to overcome these problems. A personal favorite is creating a checklist of problem areas, then checking those areas after each coding session. Eventually, I find that I don't make that mistake anymore and can take it off the list. As my coding proficiency increases, other problems appear and I add them to the list. Eventually, the list is empty—the learning process is complete and gotchas are a thing of the past.

that defies using an IntPtr. That's where using pointers comes into play. In fact, there are three well-defined situations where you'll use pointers in your C# code.

•Accessing data structures you can't replicate using managed code.

•Low-level COM or PInvoke scenarios, especially if you work with device drivers or directly with the display.

•Situations where you need the ultimate in performance and using a large number of IntPtr objects will slow the code significantly.

You'll want to keep unsafe code sections extremely small because CLR can't verify the code as safe. This has some odd ramifications in the execution of your code. For one thing, it means that the compiler won't catch as many programming errors, so you'll spend more time debugging the code. However, unsafe code also has ramifications for security (the code will often fail to execute in remote applications). In addition, you'll find that you need to watch memory allocation carefully. Using unsafe code means that you can create and delete pointers that reference memory that CLR might not deallocate automatically.

Moving Your Business Logic

At the lowest rung of the conversion ladder is your business logic. Often a routine that performs calculations, exercises rules, or performs other business logic tasks contains few, if any, calls to the Windows API. Theoretically, you can cut this code out of your Visual C++ application and paste it into a C# application. The only caveat is that you need to watch for type differences in variables. If you used good programming techniques, it should be relatively easy to locate the variable declarations and redefine them in terms that C# can understand.

The bottom line is that your Visual C++ code investment isn't lost when you move to C#. You should be able to move at least some of it directly to the new environment and access most of it using standard techniques such as component import or PInvoke. Using wrapper code as appropriate will help you access the remaining code that C# can't access directly because it appears in a library (LIB) file or some other format that C# can't understand.

Where Do You Go From Here?

One of the premises for .NET is to make life easier for the developer. In large part .NET does succeed in this goal. You'll find that you can create code faster and with fewer errors. While initial .NET projects can prove difficult, eventually you'll find that you work faster and that the learning curve for new areas is relatively small. With this in mind, your first stop after reading this book is putting some of your new-found knowledge to use in creating new C# applications.

After you have some basic knowledge of how C# works, try porting some of your existing code. Make sure you keep the problems that cause most Visual C++ developers in mind as you port the code. In addition, try using some of the tricks in the "Converting Your Existing Code to .NET" section to make the conversion process easier.

You have seen several examples of where .NET isn't quite as a complete solution as Microsoft would have you believe. For example, we had to rely entirely on a Visual C++ LIB to work with some security features in Chapter 9. In many cases, you'll find that you need both your

Visual C++ and your C# skills to remain competitive today. Eventually, Microsoft will port the rest of the code you need to .NET (or find alternative solutions). However, today's development needs will still require you to work with both Visual C++ and C# at times to accomplish specific goals.

Appendix B: C# for Visual Basic Developers

Overview

Visual Basic is one of the most popular programming languages in the Windows community today. It enables developers to write applications quickly and to use prototyping to design an application interface long before the developer commits to coding. In fact, Visual Basic is so popular that its rise to fame surprised even Microsoft. In short, Visual Basic is the success that every language development company would like to see in a language.

Of course, this begs the question of why someone who develops applications with Visual Basic would even consider using C# for application development. In most respects, if you know the .NET Framework (a requirement for using Visual Basic .NET), then you also know a great deal about C#. Visual Basic .NET is a new language in many ways—a new language with extended capabilities and functionality.

However, C# brings a lot of more to the application development environment than a simple means of accessing the .NET Framework. Special keywords, such as unsafe, make C# a little lower level language than Visual Basic, but not quite as low-level as Visual C++. This intermediate orientation makes C# more accessible to Visual Basic developers who need to write some low-level code. C# also offers a terseness not found in Visual Basic. Put simply, C# is another tool for your toolbox that meets specific needs.

This appendix isn't designed to convince anyone of the need to use one language or another for development purposes. What you will learn is how C# differs from Visual Basic, which may provide reasons for adding C# to your language toolkit. The sections that follow will also enable you to learn how to work with C# faster. You'll also learn how to perform tasks such as moving your existing Visual Basic code to C# when the situation warrants. Of course, the reasons and goals for working with C# when your main language is Visual Basic is entirely a personal choice.

An Overview of the Differences

One of the best ways to understand when to use C# for development over Visual Basic is to understand how the two languages differ. Knowing that Visual Basic and C# have many similarities (despite the curly braces found in C#), makes it easier to transition between the two languages as needed. However, it's the differences between the two languages that make one language more appropriate than the other is for some types of development. The ability to use pointers in C# makes a big difference when you need to access Windows API functions (something that happens more often than you might expect). On the other hand, Visual Basic is still faster to use in some cases, because it hides some of the details from the developer.

Note Visual Basic readers might want to look at the "An Overview of the Differences" section in Appendix A as well. This section discusses some common differences

between C# and other languages. For example, both Visual Basic and Visual C++ users will gain from the inclusion of the unsafe keyword in C#. This particular feature is discussed in Appendix A.

Differences in Syntax

At least a few of the oddities that Visual Basic programmers will experience when using C# deal with the language constructs. For example, when you want to check if an object is empty in Visual Basic, you compare it to the keyword Nothing. On the other hand, C# uses the NULL keyword, which is the same as Visual C++. Some Visual Basic programmer somewhere will probably spend hours trying to determine the error in their code due to small language differences such as this one. The small differences cause more problems than the large ones at times.

One area where Visual Basic and C# developers have a high level of agreement is in data types and variables. It's true that C# developers don't use the Dim statement to create variables, but in many other ways, assignment and usage are the same. The big difference between Visual Basic and C# in this area, is that C# enforces data types. Type conversions follow strict rules in C#, when such conversions are possible. C# also follows strict rules for variable usage. A developer must declare a variable and assign it a value before using it. You could consider C# the strict cousin of Visual Basic.

Just how strict C# becomes about some types of type conversion depends on the use of the checked versus unchecked state of computations and data conversions. You can perform certain types of conversions using C# where the data is truncated if you maintain an unchecked environment. The moment that you begin using a checked environment, C# considers any form of truncation or other unsafe data conversion to be an error. In some cases, it won't even compile the application. Here is a simple example of the differences between checked and unchecked code.

public static int Main(string[] args)

{

// Create an integer. int MyInt = 355; byte MyByte1 = 0; byte MyByte2 = 0;

// Try to create a byte form with checked on. try

{

// The conversion will fail. MyByte1 = checked((byte) MyInt);

}

catch

{

//Display an error message if the

//conversion fails.

Console.WriteLine("Can't convert int to byte.");

}

try

{

MyByte2 = unchecked((byte)MyInt);

}

catch