invisible scanner
17 February 2011
16 February 2011
Sequential Access Collections in C# .NET
A sequential access collection is a list that stores its elements in sequential order. We call this type of collection a linear list. Linear lists are not limited by size when they are created, meaning they are able to expand and contract dynamically. Items in a linear list are not accessed directly; they are referenced by their position, as shown in Figure 1.2. The first element of a linear list is at the front of the list and the last element is at the rear of the list.
Because there is no direct access to the elements of a linear list, to access an element you have to traverse through the list until you arrive at the position of the element you are looking for. Linear list implementations usually allow two methods for traversing a list—in one direction from front to rear, and from both front to rear and rear to front.
A simple example of a linear list is a grocery list. The list is created by writing down one item after another until the list is complete. The items are removed from the list while shopping as each item is found. Linear lists can be either ordered or unordered. An ordered list has values
in order in respect to each other, as in:
Beata Bernica David Frank Jennifer Mike Raymond Terrill
An unordered list consists of elements in any order.
The order of a list makes a big difference when performing searches on the data on the list, as you’ll see in a next post when we explore the binary search algorithm versus a simple linear search.
Some types of linear lists restrict access to their data elements. Examples of these types of lists are stacks and queues.
A stack is a list where access is restricted to the beginning (or top) of the list. Items are placed on the list at the top and can only be removed from the top. For this reason, stacks are known as Last-in, First-out structures. When we add an item to a stack, we call the operation a push.
When we remove an item from a stack, we call that operation a pop. These two stack operations are shown in Figure 1.3. The stack is a very common data structure, especially in computer systems programming.
Stacks are used for arithmetic expression evaluation and for balancing symbols, among its many applications.
A queue is a list where items are added at the rear of the list and removed from the front of the list.
This type of list is known as a First-in, First-out structure. Adding an item to a queue is called an EnQueue, and removing an item from a queue is called a Dequeue. Queue operations are shown in Figure 1.4.
Queues are used in both systems programming, for scheduling operating system tasks, and for simulation studies.
Queues make excellent structures for simulating waiting lines in every conceivable retail situation.
A special type of queue, called a priority queue, allows the item in a queue with the highest priority to be removed from the queue first. Priority queues can be used to study the operations of a hospital emergency room, where patients with heart trouble need to be attended to before a patient with a broken arm, for example.
The last category of linear collections we’ll examine are called generalized indexed collections. The first of these, called a hash table, stores a set of data
values associated with a key. In a hash table, a special function, called a hash function, takes one data value and transforms the value (called the key) into an integer index that is used to retrieve the data.
The index is then used to access the data record associated with the key. For example, an employee record may consist of a person’s name, his or her salary, the number of years the employee has been with the company, and the department he or she works in.
This structure is shown in Figure 1.5. The key to this data record is the employee’s name. C# has a class, called HashTable, for storing data in a hash table.
Another generalized indexed collection is the dictionary. A dictionary is made up of a series of key–value pairs, called associations. This structure is analogous to a word dictionary, where a word is the key and the word’s definition is the value associated with the key. The key is an index into the value associated with the key.
Dictionaries are often called associative arrays because of this indexing scheme, though the index does not have to be an integer.
Tweet
Direct Access Collections C# .NET
The most common example of a direct access collection is the array.We define an array as a collection of elements with the same data type that are directly accessed via an integer index, as illustrated in Figure 1.1.
Arrays can be static so that the number of elements specified when the array is declared is fixed for the length of the program, or they can be dynamic, where the number of elements can be increased via the ReDim or ReDim Preserve statements.
In C#, arrays are not only a built-in data type, they are also a class.
We can use an array to store a linear collection. Adding new elements to an array is easy since we simply place the new element in the first free position at the rear of the array. Inserting an element into an array is not as easy (or efficient), since we will have to move elements of the array down in order to make room for the inserted element.
Deleting an element from the end of an array is also efficient, since we can simply remove the value from the last element. Deleting an element in any other position is less efficient because, just as with inserting, we will probably have to adjust many array elements up one position to keep the elements in the array contiguous.
The .NET Framework provides a specialized array class, ArrayList, for making linear collection programming easier. Another type of direct access collection is the string. A string is a collection of characters that can be accessed based on their index, in the same manner we access the elements of an array. Strings are also implemented as class objects in C#. The class includes a large set of methods for performing standard operations on strings, such as concatenation, returning substrings, inserting characters, removing characters, and so forth.
C# strings are immutable, meaning once a string is initialized it cannot be changed. When you modify a string, a copy of the string is created instead of changing the original string. This behavior can lead to performance degradation in some cases, so the .NET Framework provides a StringBuilder class that enables you to work with mutable strings.
The final direct access collection type is the struct (also called structures and records in other languages). A struct is a composite data type that holds data that may consist of many different data types.
For example, an employee record consists of employee’ name (a string), salary (an integer), identification number (a string, or an integer), as well as other attributes. Since storing each of these data values in separate variables could become confusing very easily, the language provides the struct for storing data of this type.
For example, an employee record consists of employee’ name (a string), salary (an integer), identification number (a string, or an integer), as well as other attributes. Since storing each of these data values in separate variables could become confusing very easily, the language provides the struct for storing data of this type.
A powerful addition to the C# struct is the ability to define methods for performing operations stored on the data in a struct. This makes a struct somewhat like a class, though you can’t inherit or derive a new type from a structure.
The following code demonstrates a simple use of a structure in C#:
The following code demonstrates a simple use of a structure in C#:
using System;
public struct Name
{
private string fname, mname, lname;
public Name(string first, string middle, string last)
{
fname = first;
mname = middle;
lname = last;
}
public string firstName
{
get
{
return fname;
}
set
{
fname = firstName;
}
}
public string middleName
{
get
{
return mname;
}
set
{
mname = middleName;
}
}
public string lastName
{
get
{
return lname;
}
set
{
lname = lastName;
}
}
public override string ToString()
{
return (String.Format("{0} {1} {2}", fname, mname,
lname));
}
public string Initials()
{
return (String.Format("{0}{1}{2}", fname.Substring(0, 1),
mname.Substring(0, 1), lname.Substring(0, 1)));
}
}
public class NameTest
{
static void Main()
{
Name myName = new Name("Michael", "Mason", "McMillan");
string fullName, inits;
fullName = myName.ToString();
inits = myName.Initials();
Console.WriteLine("My name is {0}.", fullName);
Console.WriteLine("My initials are {0}.", inits);
}
}
Although many of the elements in the .NET environment are implemented as classes (such as arrays and strings), several primary elements of the language are implemented as structures, such as the numeric data types. The Integer data type, for example, is implemented as the Int32 structure. One of the methods you can use with Int32 is the Parse method for converting the string representation of a number into an integer. Here’s an example:
using System;
public class IntStruct
{
static void Main()
{
int num;
string snum;
Console.Write("Enter a number: ");
snum = Console.ReadLine();
num = Int32.Parse(snum);
Console.WriteLine(num);
}
}
Tweet
Collections defined in C# .NET
A collection is a structured data type that stores data and provides operations for adding data to the collection, removing data from the collection, updating data in the collection, as well as operations for setting and returning the values of different attributes of the collection.
Collections can be broken down into two types: linear and nonlinear.
A linear collection is a list of elements where one element follows the previous element.
Elements in a linear collection are normally ordered by position (first, second, third, etc.). In the real world, a grocery list is a good example of a linear collection; in the computer world (which is also real), an array is designed as a linear collection.
Nonlinear collections hold elements that do not have positional order within the collection. An organizational chart is an example of a nonlinear collection, as is a rack of billiard balls. In the computer world, trees, heaps, graphs, and sets are nonlinear collections.
Collections, be they linear or nonlinear, have a defined set of properties that describe them and operations that can be performed on them. An example of a collection property is the collections Count, which holds the number of items in the collection. Collection operations, called methods, include Add (for adding a new element to a collection), Insert (for adding a new element to a collection at a specified index), Remove (for removing a specified element from a collection), Clear (for removing all the elements from a collection), Contains (for determining if a specified element is a member of a collection), and IndexOf (for determining the index of a specified element in a collection).
Tweet
Data structures and algorithms with C# , .NET
I will write new post from now and we'll discuss the development and implementation of data structures and algorithms using C#. The data structures we use in this articles are found in the .NET Framework class library System.Collections. In this chapter, we develop the concept of a collection by first discussing the implementation of our own Collection class (using the array as the basis of our implementation) and then by covering the Collection classes in the .NET Framework.
An important addition to C# 2.0 is generics. Generics allow the C# programmer to write one version of a function, either independently or within a class, without having to overload the function many times to allow for different data types. C# 2.0 provides a special library, System.Collections.Generic,that implements generics for several of the System.Collections data structures.
This will introduce the reader to generic programming. Finally, introduces a custom-built class, theTiming class, which we will use in several chapters to measure the performance of a data structure and/or algorithm. This class will take the place of Big O analysis, not because Big O analysis isn’t important, but because this book takes a more practical approach to the study of data structures and algorithms.
05 January 2011
The C# Programming Language. What is C# ?
- What is .NET ?
programming language, C# (pronounced “see sharp”), specifically for this new platform. C# is a programming
language whose core syntax looks very similar to the syntax of Java. However, to call C# a Java rip-off is inaccurate. Both C# and Java are members of the C family of programming languages
(C, Objective C, C++, etc.) and therefore share a similar syntax. Just as Java is in many ways a
cleaned-up version of C++, C# can be viewed as a cleaned-up version of Java.
The truth of the matter is that many of C#’s syntactic constructs are modeled after various
aspects of Visual Basic 6.0 and C++. For example, like VB6, C# supports the notion of formal type
properties (as opposed to traditional getter and setter methods) and the ability to declare methods
taking a varying number of arguments (via parameter arrays). Like C++, C# allows you to overload
operators, as well as to create structures, enumerations, and callback functions (via delegates).
Due to the fact that C# is a hybrid of numerous languages, the result is a product that is as syntactically
clean—if not cleaner—than Java, is about as simple as VB6, and provides just about as
much power and flexibility as C++ (without the associated ugly bits). Here is a partial list of core C#
features that are found in all versions of the language:
• No pointers required! C# programs typically have no need for direct pointer manipulation
(although you are free to drop down to that level if absolutely necessary).
• Automatic memory management through garbage collection. Given this, C# does not support
a delete keyword.
• Formal syntactic constructs for classes, interfaces, structures, enumerations, and delegates.
• The C++-like ability to overload operators for a custom type, without the complexity (e.g.,
making sure to “return *this to allow chaining” is not your problem).
• Support for attribute-based programming. This brand of development allows you to annotate
types and their members to further qualify their behavior.
With the release of .NET 2.0 (circa 2005), the C# programming language was updated to support
numerous new bells and whistles, most notably the following:
• The ability to build generic types and generic members. Using generics, you are able to build
very efficient and type-safe code that defines numerous “placeholders” specified at the time
you interact with the generic item.
• Support for anonymous methods, which allow you to supply an inline function anywhere a
delegate type is required.
• Numerous simplifications to the delegate/event model, including covariance, contravariance,
and method group conversion.
• The ability to define a single type across multiple code files (or if necessary, as an in-memory
representation) using the partial keyword.
As you might guess, .NET 3.5 adds even more functionality to the C# programming language
(C# 2008, to be exact), including the following features:
• Support for strongly typed queries (a la LINQ, or Language Integrated Query) used to interact
with various forms of data
• Support for anonymous types, which allow you to model the “shape” of a type rather than its
behavior
• The ability to extend the functionality of an existing type using extension methods
• Inclusion of a lambda operator (=>), which even further simplifies working with .NET delegate
types
• A new object initialization syntax, which allows you to set property values at the time of
object creation
Perhaps the most important point to understand about the C# language is that it can only produce
code that can execute within the .NET runtime (you could never use C# to build a native COM
server or an unmanaged Win32 API application). Officially speaking, the term used to describe the
code targeting the .NET runtime is managed code. The binary unit that contains the managed code
is termed an assembly (more details on assemblies in just a bit in the section “An Overview of .NET
Assemblies”). Conversely, code that cannot be directly hosted by the .NET runtime is termed
unmanaged code.
The Philosophy of .NET. Why we need .NET ?
Every few years or so, the modern-day programmer must be willing to perform a self-inflicted
knowledge transplant to stay current with the new technologies of the day. The languages (C++,
Visual Basic 6.0, Java), frameworks (OWL, MFC, ATL, STL), architectures (COM, CORBA, EJB), and
APIs (such as .NET’s Windows Forms and GDI+ libraries) that were touted as the silver bullets of
software development eventually become overshadowed by something better or at the very least
something new. Regardless of the frustration you can feel when upgrading your internal knowledge
base, it is frankly unavoidable. To this end, the goal of this book is to examine the details of Microsoft’s
current offering within the landscape of software engineering: the .NET platform and the C# programming
language.
The point of this chapter is to lay the conceptual groundwork for the remainder of the book.
Here you will find a high-level discussion of a number of .NET-related topics such as assemblies, the
common intermediate language (CIL), and just-in-time (JIT) compilation. In addition to previewing
some key features of the C# programming language, you will also come to understand the
relationship between various aspects of the .NET Framework, such as the common language runtime
(CLR), the Common Type System (CTS), and the Common Language Specification (CLS).
This chapter also provides you with a survey of the functionality supplied by the .NET
base class libraries, sometimes abbreviated as the BCL or alternatively as the FCL (being the
Framework class libraries). Finally, this chapter overviews the language-agnostic and platformindependent
nature of the .NET platform(yes it’s true, .NET is not confined to the Windows
operating system). As you would hope, all of these topics are explored in further detail throughout
the remainder of this text.
Understanding the Previous State of Affairs
Before examining the specifics of the .NET universe, it’s helpful to consider some of the issues that
motivated the genesis of Microsoft’s current platform. To get in the proper mind-set, let’s begin this
chapter with a brief and painless history lesson to remember our roots and understand the limitations
of the previous state of affairs (after all, admitting you have a problem is the first step toward
finding a solution). After completing this quick tour of life as we knew it, we turn our attention to
the numerous benefits provided by C# and the .NET platform.
Life As a C/Win32 API Programmer
Traditionally speaking, developing software for the Windows family of operating systems involved
using the C programming language in conjunction with the Windows application programming
interface (API). While it is true that numerous applications have been successfully created using this
time-honored approach, few of us would disagree that building applications using the raw API is a
complex undertaking.
The first obvious problem is that C is a very terse language. C developers are forced to contend
with manual memory management, ugly pointer arithmetic, and ugly syntactical constructs. Furthermore,
given that C is a structured language, it lacks the benefits provided by the object-oriented
approach (can anyone say spaghetti code?). When you combine the thousands of global functions
and data types defined by the Win32 API to an already formidable language, it is little wonder that
there are so many buggy applications floating around today.
Life As a C++/MFC Programmer
One vast improvement over raw C/API development is the use of the C++ programming language.
In many ways, C++ can be thought of as an object-oriented layer on top of C. Thus, even though
C++ programmers benefit from the famed “pillars of OOP” (encapsulation, inheritance, and polymorphism),
they are still at the mercy of the painful aspects of the C language (e.g., manual memory
management, ugly pointer arithmetic, and ugly syntactical constructs).
Despite its complexity, many C++ frameworks exist today. For example, the Microsoft Foundation
Classes (MFC) provide the developer with a set of C++ classes that facilitate the construction of
Win32 applications. The main role of MFC is to wrap a “sane subset” of the raw Win32 API behind a
number of classes, magic macros, and numerous code-generation tools (a.k.a. wizards). Regardless
of the helpful assistance offered by the MFC framework (as well as many other C++-based windowing
toolkits), the fact of the matter is that C++ programming remains a difficult and error-prone
experience, given its historical roots in C.
Life As a Visual Basic 6.0 Programmer
Due to a heartfelt desire to enjoy a simpler lifestyle, many programmers have shifted away from the
world of C(++)-based frameworks to kinder, gentler languages such as Visual Basic 6.0 (VB6). VB6 is
popular due to its ability to build complex user interfaces, code libraries (e.g., COM servers), and
data access logic with minimal fuss and bother. Even more than MFC, VB6 hides the complexities
of the raw Win32 API from view using a number of integrated code wizards, intrinsic data types,
classes, and VB-specific functions.
The major downfall of VB6 (which has been rectified given the advent of the .NET platform) is
that it is not a fully object-oriented language; rather, it is “object aware.” For example, VB6 does not
allow the programmer to establish “is-a” relationships between types (i.e., no classical inheritance)
and has no intrinsic support for parameterized class construction. Moreover, VB6 doesn’t provide
the ability to build multithreaded applications unless you are willing to drop down to low-level
Win32 API calls (which is complex at best and dangerous at worst).
Life As a Java/J2EE Programmer
Enter Java. Java is an object-oriented programming language that has its syntactic roots in C++. As
many of you are aware, Java’s strengths are far greater than its support for platform independence.
Java (as a language) cleans up many unsavory syntactical aspects of C++. Java (as a platform)
provides programmers with a large number of predefined “packages” that contain various type
definitions. Using these types, Java programmers are able to build “100% Pure Java” applications
complete with database connectivity, messaging support, web-enabled front ends, and a rich
desktop user interface.
Although Java is a very elegant language, one potential problem is that using Java typically
means that you must use Java front-to-back during the development cycle. In effect, Java offers little
hope of language integration, as this goes against the grain of Java’s primary goal (a single programming
language for every need). In reality, however, there are millions of lines of existing code out there in the world that would ideally like to commingle with newer Java code. Sadly, Java makes this
task problematic. While Java does provide a limited ability to access non-Java APIs, there is little
support for true cross-language integration.
The .NET Solution
So much for the brief history lesson. The bottom line is that life as a Windows programmer has been
tough. The .NET Framework is a rather radical and brute-force approach to making our lives easier.
The solution proposed by .NET is “Change everything” (sorry, you can’t blame the messenger for the
message). As you will see during the remainder of this book, the .NET Framework is a completely
new model for building systems on the Windows family of operating systems, as well as on numerous
non-Microsoft operating systems such as Mac OS X and various Unix/Linux distributions. To
set the stage, here is a quick rundown of some core features provided courtesy of .NET:
• Comprehensive interoperability with existing code: This is (of course) a good thing. Existing
COM binaries can commingle (i.e., interop) with newer .NET binaries and vice versa. Also,
PlatformInvocation Services (PInvoke) allows you to call C-based libraries (including the
underlying API of the operating system) from .NET code.
• Complete and total language integration: .NET supports cross-language inheritance, crosslanguage
exception handling, and cross-language debugging of code.
• A common runtime engine shared by all .NET-aware languages: One aspect of this engine is a
well-defined set of types that each .NET-aware language “understands.”
• A comprehensive base class library: This library provides shelter from the complexities of raw
API calls and offers a consistent object model used by all .NET-aware languages.
• No more COM plumbing: IClassFactory, IUnknown, IDispatch, IDL code, and the evil variantcompliant
data types (BSTR, SAFEARRAY, and so forth) have no place in a .NET binary.
• A truly simplified deployment model: Under .NET, there is no need to register a binary unit
into the system registry. Furthermore, .NET allows multiple versions of the same *.dll to
exist in harmony on a single machine.
As you can most likely gather from the previous bullet points, the .NET platform has nothing to
do with COM (beyond the fact that both frameworks originated from Microsoft). In fact, the only
way .NET and COM types can interact with each other is using the interoperability layer.
knowledge transplant to stay current with the new technologies of the day. The languages (C++,
Visual Basic 6.0, Java), frameworks (OWL, MFC, ATL, STL), architectures (COM, CORBA, EJB), and
APIs (such as .NET’s Windows Forms and GDI+ libraries) that were touted as the silver bullets of
software development eventually become overshadowed by something better or at the very least
something new. Regardless of the frustration you can feel when upgrading your internal knowledge
base, it is frankly unavoidable. To this end, the goal of this book is to examine the details of Microsoft’s
current offering within the landscape of software engineering: the .NET platform and the C# programming
language.
The point of this chapter is to lay the conceptual groundwork for the remainder of the book.
Here you will find a high-level discussion of a number of .NET-related topics such as assemblies, the
common intermediate language (CIL), and just-in-time (JIT) compilation. In addition to previewing
some key features of the C# programming language, you will also come to understand the
relationship between various aspects of the .NET Framework, such as the common language runtime
(CLR), the Common Type System (CTS), and the Common Language Specification (CLS).
This chapter also provides you with a survey of the functionality supplied by the .NET
base class libraries, sometimes abbreviated as the BCL or alternatively as the FCL (being the
Framework class libraries). Finally, this chapter overviews the language-agnostic and platformindependent
nature of the .NET platform(yes it’s true, .NET is not confined to the Windows
operating system). As you would hope, all of these topics are explored in further detail throughout
the remainder of this text.
Understanding the Previous State of Affairs
Before examining the specifics of the .NET universe, it’s helpful to consider some of the issues that
motivated the genesis of Microsoft’s current platform. To get in the proper mind-set, let’s begin this
chapter with a brief and painless history lesson to remember our roots and understand the limitations
of the previous state of affairs (after all, admitting you have a problem is the first step toward
finding a solution). After completing this quick tour of life as we knew it, we turn our attention to
the numerous benefits provided by C# and the .NET platform.
Life As a C/Win32 API Programmer
Traditionally speaking, developing software for the Windows family of operating systems involved
using the C programming language in conjunction with the Windows application programming
interface (API). While it is true that numerous applications have been successfully created using this
time-honored approach, few of us would disagree that building applications using the raw API is a
complex undertaking.
The first obvious problem is that C is a very terse language. C developers are forced to contend
with manual memory management, ugly pointer arithmetic, and ugly syntactical constructs. Furthermore,
given that C is a structured language, it lacks the benefits provided by the object-oriented
approach (can anyone say spaghetti code?). When you combine the thousands of global functions
and data types defined by the Win32 API to an already formidable language, it is little wonder that
there are so many buggy applications floating around today.
Life As a C++/MFC Programmer
One vast improvement over raw C/API development is the use of the C++ programming language.
In many ways, C++ can be thought of as an object-oriented layer on top of C. Thus, even though
C++ programmers benefit from the famed “pillars of OOP” (encapsulation, inheritance, and polymorphism),
they are still at the mercy of the painful aspects of the C language (e.g., manual memory
management, ugly pointer arithmetic, and ugly syntactical constructs).
Despite its complexity, many C++ frameworks exist today. For example, the Microsoft Foundation
Classes (MFC) provide the developer with a set of C++ classes that facilitate the construction of
Win32 applications. The main role of MFC is to wrap a “sane subset” of the raw Win32 API behind a
number of classes, magic macros, and numerous code-generation tools (a.k.a. wizards). Regardless
of the helpful assistance offered by the MFC framework (as well as many other C++-based windowing
toolkits), the fact of the matter is that C++ programming remains a difficult and error-prone
experience, given its historical roots in C.
Life As a Visual Basic 6.0 Programmer
Due to a heartfelt desire to enjoy a simpler lifestyle, many programmers have shifted away from the
world of C(++)-based frameworks to kinder, gentler languages such as Visual Basic 6.0 (VB6). VB6 is
popular due to its ability to build complex user interfaces, code libraries (e.g., COM servers), and
data access logic with minimal fuss and bother. Even more than MFC, VB6 hides the complexities
of the raw Win32 API from view using a number of integrated code wizards, intrinsic data types,
classes, and VB-specific functions.
The major downfall of VB6 (which has been rectified given the advent of the .NET platform) is
that it is not a fully object-oriented language; rather, it is “object aware.” For example, VB6 does not
allow the programmer to establish “is-a” relationships between types (i.e., no classical inheritance)
and has no intrinsic support for parameterized class construction. Moreover, VB6 doesn’t provide
the ability to build multithreaded applications unless you are willing to drop down to low-level
Win32 API calls (which is complex at best and dangerous at worst).
Life As a Java/J2EE Programmer
Enter Java. Java is an object-oriented programming language that has its syntactic roots in C++. As
many of you are aware, Java’s strengths are far greater than its support for platform independence.
Java (as a language) cleans up many unsavory syntactical aspects of C++. Java (as a platform)
provides programmers with a large number of predefined “packages” that contain various type
definitions. Using these types, Java programmers are able to build “100% Pure Java” applications
complete with database connectivity, messaging support, web-enabled front ends, and a rich
desktop user interface.
Although Java is a very elegant language, one potential problem is that using Java typically
means that you must use Java front-to-back during the development cycle. In effect, Java offers little
hope of language integration, as this goes against the grain of Java’s primary goal (a single programming
language for every need). In reality, however, there are millions of lines of existing code out there in the world that would ideally like to commingle with newer Java code. Sadly, Java makes this
task problematic. While Java does provide a limited ability to access non-Java APIs, there is little
support for true cross-language integration.
The .NET Solution
So much for the brief history lesson. The bottom line is that life as a Windows programmer has been
tough. The .NET Framework is a rather radical and brute-force approach to making our lives easier.
The solution proposed by .NET is “Change everything” (sorry, you can’t blame the messenger for the
message). As you will see during the remainder of this book, the .NET Framework is a completely
new model for building systems on the Windows family of operating systems, as well as on numerous
non-Microsoft operating systems such as Mac OS X and various Unix/Linux distributions. To
set the stage, here is a quick rundown of some core features provided courtesy of .NET:
• Comprehensive interoperability with existing code: This is (of course) a good thing. Existing
COM binaries can commingle (i.e., interop) with newer .NET binaries and vice versa. Also,
PlatformInvocation Services (PInvoke) allows you to call C-based libraries (including the
underlying API of the operating system) from .NET code.
• Complete and total language integration: .NET supports cross-language inheritance, crosslanguage
exception handling, and cross-language debugging of code.
• A common runtime engine shared by all .NET-aware languages: One aspect of this engine is a
well-defined set of types that each .NET-aware language “understands.”
• A comprehensive base class library: This library provides shelter from the complexities of raw
API calls and offers a consistent object model used by all .NET-aware languages.
• No more COM plumbing: IClassFactory, IUnknown, IDispatch, IDL code, and the evil variantcompliant
data types (BSTR, SAFEARRAY, and so forth) have no place in a .NET binary.
• A truly simplified deployment model: Under .NET, there is no need to register a binary unit
into the system registry. Furthermore, .NET allows multiple versions of the same *.dll to
exist in harmony on a single machine.
As you can most likely gather from the previous bullet points, the .NET platform has nothing to
do with COM (beyond the fact that both frameworks originated from Microsoft). In fact, the only
way .NET and COM types can interact with each other is using the interoperability layer.
Subscribe to:
Posts (Atom)