计算机c语言专业外文翻译-c语言(编辑修改稿)

计算机c语言专业外文翻译-c语言(编辑修改稿)内容摘要：

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 patibility 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. Let39。 s look at a realworld example that would benefit from interfaces to illustrate its extremely positive role in C. Many applications available today support addins. Assume that you have created a code editor for writing applications. This code editor, when executed, has the capability to load addins. To do this, the addin must follow a few rules. The DLL addin 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 addin. This method of creating and loading addins is very burdensome because it burdens the code editor with more verification duties than necessary. If an interface were used in this instance, your addin 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 selfdescribing, 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 piler 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 piler is written in a language called Microsoft Intermediate Language, or MSIL. MSIL is made up of a specific set of instructions 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 pilation process. All .NETpatible languages, including Visual Basic .NET and Managed C++, produce MSIL when their source code is piled. Because all of the .NET languages pile to the same MSIL instruction set, and because all of the .NET languages use the same runtime, code from different languages and different pilers 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 can39。 t read MSIL? The answer is that the MSIL code is turned into CPUspecific code when the code is run for the first time. This process is called justintime pilation, or JIT. The job of a JIT piler 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 piler could generate CPUspecific code directly? After all, pilers have always done this in the past. There are a couple of reasons for this. First, MSIL enables your piled code to be easily moved to different hardware. Suppose you39。 ve written some C code and you39。 d like it to run on both your desktop and a handheld device. It39。 s very likely that those two devices have different types of CPUs. If you only had a C piler that targeted a specific CPU, then you39。 d need two C pilers: one that targeted your desktop CPU and another that targeted your handheld CPU. You39。 d have to pile your code twice, ensuring that you put the right code on the right device. With MSIL, you pile once. Installing the .NET Framework on your desktop machine includes a JIT piler that translates your MSIL into CPUspecific code for your desktop. Installing the .NET Framework on your handheld includes a JIT piler that translates that same MSIL into CPUspecific code for your handheld. You now have a single MSIL code base that can run on any device that has a .NET JIT piler. The JIT piler on that device takes care of making your code run on the device. Another reason for the piler39。 s use of MSIL is that the instruction set can be easily read by a verification process. Part of the job of the JIT piler is to verify your code to ensure that。