12、毕业设计(论文)外文参考中文译文格式

北京航空航天大学北海学院

毕业设计（论文）外文文献译文

英文译文：

C# Programming Language Overview

A History of C, C++, and C#

The C# programming language was created in the spirit of the C and C++ programming languages. This accounts for its powerful features and easy learning curve. The same can't be said for C and C++, but because C# was created from the ground up, Microsoft took the liberty of removing some of the more burdensome features — such as pointers. This section takes a look at the C and C++ languages, tracing their evolution into C#.

The C programming language was originally designed for use on the UNIX operating system. C was used to create many UNIX applications, including a C compiler, and was eventually used to write UNIX itself. Its widespread acceptance in the academic arena expanded to include the commercial world, and software vendors such as Microsoft and Borland released C compilers for personal computers. The original Windows API was designed to work with Windows code written in C, and the latest set of the core Windows operating system APIs remain compatible with C to this day.

From a design standpoint, C lacked a detail that other languages such as Smalltalk had already embraced: the concept of an object. You'll learn more about objects in Chapter 8, " Writing Object-Oriented Code." For now, think of an object as a collection of data and a set of operations that can be performed on that data. Object-style coding could be accomplished using C, but the notion of an object was not enforced by the language. If you wanted to structure your code to resemble an object, fine. If you didn't, fine. C really didn't care. Objects weren't an inherent part of the language, so many people didn't pay much attention to this programming paradigm.

After the notion of object-oriented development began to gainacceptance, it became clear that C needed to be refined to embrace this new way of thinking about code. C++ was created to embody this refinement. It was designed to be backwardly compatible with C (such that all C programs would also be C++ programs and could be compiled with a C++ compiler). The major addition to the C++ language was support for this new object concept. The C++ language added support for classes (which are "templates" of objects), and enabled an entire generation of C programmers to think in terms of objects and their behavior.

The C++ language is an improvement over C, but it still has some disadvantages. C and C++ can be hard to get a handle on. Unlike easy-to-use languages like Visual Basic, C and C++ are very "low level" and require you to do a lot of coding to make your application run well. You have to write your own code to handle issues such as memory management and error checking. C and C++ can result in very powerful applications, but you need to ensure that your code works well. One bug can make the entire application crash or behave unexpectedly.

Because of the C++ design goal of retaining backward compatibility with C, C++ was unable to break away from the low level nature of C.

Microsoft designed C# to retain much of the syntax of C and C++. Developers who are familiar with those languages can pick up C# code and begin coding relatively quickly. The big advantage to C#, however, is that its designers chose not to make it backwardly compatible with C and C++. While this may seem like a bad deal, it's actually good news. C# eliminates the things that makes C and C++ difficult to work with. Because all C code is also C++ code, C++ had to retain all of the original quirks and deficiencies found in C. C# is starting with a clean slate and without any compatibility requirements, so it can retain the strengths of its predecessors and discard the weaknesses that made life hard for C and C++ programmers.

Introducing C#

C#, the new language introduced in the .NET Framework, is derived from C++. However, C# is a modern, objected-oriented (from the ground up) type-safe language.

Language features.

The following sections take a quick look at some of the features of the C# language. If some of these concepts don't sound familiar to you, don't worry. All of them are covered in detail in later chapters. Classes

All code and data in C# must be enclosed in a class. You can't define a variable outside of a class, and you can't write any code that's not in a class. Classes can have constructors, which execute when an object of the class is created, and a destructor, which executes when an object of the class is destroyed. Classes support single inheritance, and all classes ultimately derive from a base class called object. C# supports versioning techniques to help your classes evolve over time while maintaining compatibility with code that uses earlier versions of your classes.

As an example, take a look at a class called Family. This class contains the two static fields that hold the first and last name of a family member as well as a method that returns the full name of the family member.

class Class1 {

public string FirstName; public string LastName; public string FullName() { }

return FirstName + LastName; }

Note Single inheritance means that a C# class can inherit from only one base class. C# enables you to group your classes into a collection of classes called a namespace. Namespaces have names, and can help organize collections of classes into logical groupings. As you begin to learn C#, it becomes apparent that all namespaces relevant to the .NET Framework begin with System. Microsoft has also chosen to include some classes that aid in backwards compatibility and API access. These classes are contained within the Microsoft namespace.

Data types

C# lets you work with two types of data: value types and reference types. Value types hold actual values. Reference types hold references to values stored elsewhere in memory. Primitive types such as char, int and float, as well as enumerated values and structures, are value types. Reference types hold variables that deal with objects and arrays. C# comes with predefined reference types (object and string), as well as predefined value types (sbyte, short, int, long, byte, ushort, uint, ulong, float, double, bool, char, and decimal). You can also define your own value and reference types in your code. All value and reference types ultimately derive from a base type called object.

C# allows you to convert a value of one type into a value of another type. You can work with both implicit conversions and explicit conversions. Implicit conversions always succeed and don't lose any information (for example, you can convert an int to a long without losing any data because a long is larger than an int). Explicit conversions may cause you to lose data (for example, converting a long into an int may result in a loss of data because a long can hold larger values than an int). You must write a cast operator into your code to make an explicit conversion happen.

Cross-Reference

Refer to Chapter 3, "Working with V about implicit and explic it conversions. You can work with both one-dimensional and multidimensional arrays in C#. Multidimensional arrays can be rectangular, in which each of the arrays has the same dimensions, or jagged, in which each of the arrays has different dimensions.

Classes and structures can have data members called properties and fields. Fields are variables that

are associated with the enclosing class or structure. You may define a structure called Employee, for example, that has a field called Name. If you define a variable of type Employee called CurrentEmployee, you can retrieve the employee's name by writing https://www.sodocs.net/doc/004788482.html,. Properties are like fields, but enable you to write code to specify what should happen when code accesses the value. If the employee's name must be read from a database, for example, you can write code that says, "when someone asks for the value of the Name property, read the name from the database and return the name as a string." Functions

A function is a callable piece of code that may or may not return a value to the code that originally called it. An example of a function would be the FullName function shown earlier, in this chapter, in the Family class. A function is generally associated to pieces of code that return information whereas a method generally does not return information. For our purposes however, we generalize and refer to them both as functions.

Functions can have four kinds of parameters:

? Input parameters have values that are sent into the function, but the function cannot change those values.

? Output parameters have no value when they are sent into the function, but the function can give them a value and send the value back to the caller.

? Reference parameters pass in a reference to another value. They have a value coming in to the function, and that value can be changed inside the function.

? Params parameters define a variable number of arguments in a list. C# and the CLR work together to provide automatic memory management. You don't need to write code that says "allocate enough memory for an integer" or "free the memory that this object was using." The CLR monitors your memory usage and automatically retrieves more when you need it. It also frees memory automatically when it detects that it is no longer being used (this is also known as Garbage Collection).

C# provides a variety of operators that enable you to write mathematical and bitwise expressions. Many (but not all) of these operators can be redefined, enabling you to change how the operators work.

C# supports a long list of statements that enable you to define various execution paths within your code. Flow control statements that use keywords such as if, switch, while, for, break and continue enable your code to branch off into different paths, depending on the values of your variables. Classes can contain code and data. Each class member has something called an accessibility scope, which defines the member's visibility to other objects. C# supports public, protected, internal, protected internal, and private accessibility scopes.

Variables

Variables can be defined as constants. Constants have values that cannot change during the execution of your code. The value of pi, for instance, is a good example of a constant, because its value won't be changing as your code runs. Enum type declarations specify a type name for a related group of constants. For example, you could define an enum of Planets with values of Mercury, V those names in your code. Using the enum names in code makes code more readable than if you used a number to represent each planet.

C# provides a built-in mechanism for defining and handling events. If you write a class that performs a lengthy operation, you may want to invoke an event when the operation is completed. Clients can subscribe to that event and catch the event in their code, which enables them to be notified when you have completed your lengthy operation. The event handling mechanism in C# uses delegates, which are variables that reference a function.

Note An event handler is a procedure in your code that determines the actions to be performed when

an event occurs, such as the user clicking a button.

If your class holds a set of values, clients may want to access the values as if your class were an array. You can write a piece of code called an indexer to enable your class to be accessed as if it were an array. Suppose you write a class called Rainbow, for example, that contains a set of the colors in the rainbow. Callers may want to write MyRainbow[0] to retrieve the first color in the rainbow. You can write an indexer into your Rainbow class to define what should be returned when the caller accesses your class, as if it were an array of values.

Interfaces

C# supports interfaces, which are groups of properties, methods, and events that specify a set of functionality. C# classes can implement interfaces, which tells users that the class supports the set of functionality documented by the interface. You can develop implementations of interfaces without interfering with any existing code, which minimizes compatibility problems. Once an interface has been published, it cannot be changed, but it can evolve through inheritance. C# classes can implement many interfaces, although the classes can only inherit from a single base class.

Let's look at a real-world example that would benefit from interfaces to illustrate its extremely positive role in C#. Many applications available today support add-ins. Assume that you have created a code editor for writing applications. This code editor, when executed, has the capability to load add-ins. To do this, the add-in must follow a few rules. The DLL add-in must export a function called CEEntry, and the name of the DLL must begin with CEd. When we run our code editor, it scans its working directory for all DLLs that begin with CEd. When it finds one, it is loaded; and then it uses the GetProcAddress to locate the CEEntry function within the DLL, thus verifying that you followed all the rules necessary to create an add-in. This method of creating and loading add-ins is very burdensome because it burdens the code editor with more verification duties than necessary. If an interface were used in this instance, your add-in DLL could have implemented an interface, thus guaranteeing that all necessary methods, properties, and events were present with the DLL itself, and functioning as documentation specified.

Attributes

Attributes declare additional information about your class to the CLR. In the past, if you wanted to make your class self-describing, you had to take a disconnected approach in which the documentation was stored in external files such as IDL or even HTML files. Attributes solve this problem by enabling you, the developer, to bind information to classes — any kind of information. For example, you can use an attribute to embed documentation information into a class. Attributes can also be used to bind runtime information to a class, defining how it should act when used. The possibilities are endless, which is why Microsoft includes many predefined attributes within the .NET Framework.

Compiling C#

Running your C# code through the C# compiler produces two important pieces of information: code and metadata. The following sections describe these two items and then finish up by examining the binary building block of .NET code: the assembly.

Microsoft Intermediate Language (MSIL)

The code that is output by the C# compiler is written in a language called Microsoft Intermediate Language, or MSIL. MSIL is made up of a specific set of ins tructions that specify how your code should be executed. It contains instructions for operations such as variable initialization, calling object methods, and error handling, just to name a few. C# is not the only language in which source code changes into MSIL during the compilation process. All .NET-compatible languages, including Visual Bas ic .NET and Managed C++, produce MSIL when their source code is compiled. Because all of the .NET languages

compile to the same MSIL instruction set, and because all of the .NET languages use the same runtime, code from different languages and different compilers can work together easily.

MSIL is not a specific instruction set for a physical CPU. It knows nothing about the CPU in your machine, and your machine knows nothing about MSIL. How, then, does your .NET code run at all, if your CPU can't read MSIL? The answer is that the MSIL code is turned into CPU-specific code when the code is run for the first time. This process is called "just-in-time" compilation, or JIT. The job of a JIT compiler is to translate your generic MSIL code into machine code that can be executed by your CPU. You may be wondering about what seems like an extra step in the process. Why generate MSIL when a compiler could generate CPU-specific code directly? After all, compilers have always done this in the past. There are a couple of reasons for this. First, MSIL enables your compiled code to be easily moved to different hardware. Suppose you've written some C# code and you'd like it to run on both your desktop and a handheld device. It's very likely that those two devices have different types of CPUs. If you only had a C# compiler that targeted a specific CPU, then you'd need two C# compilers: one that targeted your desktop CPU and another that targeted yourhandheld CPU. You'd have to compile your code twice, ensuring that you put the right code on the right device. With MSIL, you compile once. Installing the .NET Framework on your desktop machine includes a JIT compiler that translates your MSIL into CPU-specific code for your desktop. Installing the .NET Framework on your handheld includes a JIT compiler that translates that same MSIL into CPU-specific code for your handheld. You now have a single MSIL code base that can run on any device that has a .NET JIT compiler. The JIT compiler on that device takes care of making your code run on the device.

Another reason for the compiler's use of MSIL is that the instruction set can be easily read by a verification process. Part of the job of the JIT compiler is to verify your code to ensure that it is as clean as possible. The verification process ensures that your code is accessing memory properly and that it is using the correct variable types when calling methods that expect a specific type. These checks ensure that your code doesn't execute any instructions that could make the code crash. The MSIL instruction set was designed to make this verification process relatively straightforward. CPU-specific instruction sets are optimized for quick execution of the code, but they produce code that can be hard to read and, therefore, hard to verify. Having a C# compiler that directly outputs CPU-specific code can make code verification difficult or even impossible. Allowing the .NET Framework JIT compiler to verify your code ensures that your code accesses memory in a bug-free way and that variable types are properly used. Metadata

The compilation process also outputs metadata, which is an important piece of the .NET code- sharing story. Whether you use C# to build an end-user application or you use C# to build a class library to be used by someone else's application, you're going to want to make use of some already-compiled .NET code. That code may be supplied by Microsoft as a part of https://www.sodocs.net/doc/004788482.html, Framework, or it may be supplied by a user over the Internet. The key to using this external code is letting the C# compiler know what classes and variables are in the other code base so that it can match up the source code you write with the code found in the precompiled code base that you'reworking with.

Think of metadata as a "table of contents" for your compiled code. The C# compiler places metadata in the compiled code along with the generated MSIL. This metadata accurately describes all the classes you wrote and how they are structured. All of the classes' methods and variable information is fully described in the metadata, ready to be read by other applications. Visual Bas ic .NET, for example, may read the metadata for a .NET library to provide the IntelliSense capability of listing all of the methods available for a particular class.

If you've ever worked with COM (Component Object Model), you may be familiar with type

libraries. Type libraries aimed to provide similar "table of contents" functionality for COM objects. However, type libraries suffered from some limitations, not the least of which was the fact that not all of the data relevant to the object was put into the type library. Metadata https://www.sodocs.net/doc/004788482.html, does not have this shortcoming. All of the information needed to describe a class in code is placed into the metadata. You can think of metadata as having all of the benefits of COM type libraries without the limitations . Assemblies

Sometimes, you will use C# to build an end-user application. These applications are packaged as executable files with an extension of .EXE. Windows has always worked with .EXE files as application programs, and C# fully supports building .EXE files.

However, there may be times when you don't want to build an entire application. Instead, you may want to build a code library that can be used by others. You may also want to build some utility classes in C#, for example, and then hand the code off to a Visual Bas ic .NET developer, who will use your classes in a Visual Basic .NET application. In cases like this, you won't be building an application. Instead, you'll be building an assembly.

An assembly is a package of code and metadata. When you deploy a set of classes in an assembly, you are deploying the classes as a unit; and those classes share the same level of version control, security information, and activation requirements. Think of an assembly as a "logical DLL." If you're familiar with Microsoft Transaction Server or COM+, you can think of an assembly as the .NET equivalent of a package.

There are two types of assemblies: private assemblies and global assemblies. When you build your assembly, you don't need to specify whether you want to build a private or a global assembly. The difference is apparent when you deploy your assembly. With a private assembly, you make your code available to a single application. Your assembly is packaged as a DLL, and is installed into the same directory as the application using it. With a deployment of a private assembly, the only application that can use your code is the executable that lives in the same directory as your assembly.

If you want to share your code among many applications, you might want to consider deploying your code as a global assembly. Global assemblies can be used by any .NET application on the system, regardless of the directory in which it is installed. Microsoft ships assemblies as a part of the .NET Framework, and each of the Microsoft assemblies is installed as a global assembly. The .NET Framework contains a list of global assemblies in a facility called the global assembly cache, and the .NET Microsoft Framework SDK includes utilities to both install and remove assemblies from the global assembly cache. In one sense, C# can be seen as being the same thing to programming languages as .NET is to the Windows environment. Just as Microsoft has been adding more and more features to Windows and the Windows API over the past decade, Visual Bas ic and C++ have undergone expansion. Although Visual Basic and C++ have ended up as hugely powerful languages as a result of this, both languages also suffer from problems due to the legacies of how they have evolved.

In the case of Visual Basic 6 and earlier, the main strength of the language was the fact that it was simple to understand and didn’t make many programming tasks easy, largely hiding the details of the Windows API and the COM component infrastructure from the developer. The downside to this was that Visual Basic was never truly object-oriented, so that large applications quickly become disorganized and hard to maintain. As well as this, because Visual Basic’s syntax was inherited from early versions of BASIC (which, in turn, was designed to be intuitively simple for beginning programmers to understand, rather than to write large commercial applications), it didn’t really lend itself to well-structured or object-oriented programs.

C++, on the other hand, has its roots in the ANSI C++ language definition. It isn’t completely ANSI

compliant for the simple reason that Microsoft first wrote its C++ compiler before the ANSI definition had become official, but it comes close. Unfortunately, this has led to two problems. First, ANSI C++ has its roots in a decade-old state of technology, and this shows up in a lack of support for modern concepts (such as Unicode strings and generating XML documentation), and in some archaic syntax structures designed for the compilers of yesteryear (such as the separation of declaration from definition of member functions). Second, Microsoft has been simultaneously trying to evolve C++ into a language that is designed for high-performance tasks on Windows, and in order to achieve tha t they’ve been forced to add a huge number of Microsoft-specific keywords as well as various libraries to the language. The result is that on Windows, the language has become a complete mess. Just ask C++ developers how many definitions for a string they can think of: char*, LPTSTR, string, CString (MFC version), CString (WTL version), wchar_t*, OLECHAR*, and so on. Now enter .NET—a completely new environment that is going to involve new extensions to both languages. Microsoft has gotten around this by adding yet more Microsoft-specific keywords to C++, and by completely revamping Visual Basic into Visual Basic .NET, a language that retains some of the basic VB syntax but that is so different in design that we can consider it to be, for all practical purp oses, a new language. It’s in this context that Microsoft has decided to give developers an alternative—a language designed specifically for .NET, and designed with a clean slate. Visual C# .NET is the result. Officially, Micros oft describes C# as a “simp le, modern, object-oriented, and type-safe programming language derived from C and C++.” Most independent observers would probably change that to “derived from C, C++, and Java.” Such descriptions are technically.

accurate but do little to convey the beauty or elegance of the language. Syntactically, C# is very similar to both C++ and Java, to such an extent that many keywords are the same, and C# also shares the same block structure with braces ({}) to mark blocks of code, and semicolons to separate statements. The first impression of a piece of C# code is that it looks quite like C++ or Java code. Behind that initial similarity, however, C# is a lot easier to learn than C++, and of comparable difficulty to Java. Its design is more in tune with modern developer tools than both of those other languages, and it has been designed to give us, simultaneous ly, the ease of use of Visual Bas ic, and the highperformance, low-level memory access of C++ if required. Some of the features of C# are:

Full support for classes and object-oriented programming, including both interface and implementation inheritance, virtual functions, and operator overloading.

A consistent and well-defined set of basic types.

Bui lt-in support for automatic generation of XML documentation. Automatic cleanup of dynamically allocated memory.

The facility to mark classes or methods with user-defined attributes. This can be useful for documentation and can havesome effects on compilation (for example, marking methods to be compiled only in debug builds).

Full access to the .NET base class library, as well as easy access to the Window s API (if you really need it, which won’t be all that often).

Pointers and direct memory access are available if required, but the language has been designed in such a way that you can work without them in almost all cases.

Support for properties and events in the style of Visual Basic.

Just by changing the compiler options, you can compile either to an executable or to a library of .NET components that can be called up by other code in the same way as ActiveX controls (COM components).

C# can be used to write https://www.sodocs.net/doc/004788482.html, dynamic Web pages and XMLWeb services.

Most of the above statements, it should be pointed out, do also apply to Visua l Basic .NET and Managed C++. The fact that C# is designed from the start to work with .NET, however, means that its support for the features of .NET is both more complete, and offered within the context of a more suitable syntax than for those other languages. While the C# language itself is very similar to Java, there are some improvements: in particular, Java is not designed to work with the .NET environment.

Before we leave the subject, we should point out a couple of limitations of C#. The one area the language is not designed for is time-critical or extremely high performance code—the kind where you really are worried about whether a loop takes 1,000 or 1,050 machine cycles to run through, and you need to clean up your resources the millisecond they are no longer needed. C++ is likely to continue to reign supreme among low-level languages in this area. C# lacks certain key facilities needed for extremely high performance apps, including the ability to specify inline functions and destructors that are guaranteed to run at particular points in the code. However, the proportions of applications that fall into this category are very low.