Visual C # .NET 2003 Language Change Prashant Sridharanmicrosoft Corporation Application December 30, 2002: Microsoft Visual Studio® C # 2003 Abstract: In order to completely compatibility with the C # specification of the European Computer Manufacturer Association (ECMA), Microsoft Corporation pair C # compiler The implementation has made several changes. These changes will affect existing code in many ways, so users must check their code to ensure that these codes meet the requirements of C # programming languages and recommendations. table of Contents
Background C # Language New Features Implementation Small Junction Background 2001 At the end of 2001, ECMA approved C # programming language as a standard (ECMA-334). In order to maintain a consistent with Microsoft in C # and public language interface (CLI) standardization process, Microsoft follows the spirit and text specification of the ECMA C # standard to make several small changes to the C # compiler. In addition, Microsoft has made some extra small changes to C # simultaneously with the C # standard specification and corrected some compilers and errors encountered by C # programmers. Each change in these may result in the use of the Visual C # .NET 2002 compiler to be modified before Visual C # .NET 2003. There are two new features in the C # language of the C # language Visual C # .NET 2003. First, the compiler now supports the #LINE Hidden Preprocessor Directive. #LINE Hidden Director is mainly used for source code generators, which informs the compiler to ignore the debugger information of all code rows behind the #LINE Hidden command until the next #LINE instruction is encountered (debugging of the #Line instruction) The program information is also ignored, here it is assumed that they will not immediately touch the next #LINE Hidden pre-processing instruction. In the following example, the compiler generates an IL code, where the WRITELINE statement does not include debugging information. In this way, debugging the programmer will not be able to view the "hidden" code and check the content: Public Class Customer
{
Public static void main ()
{
Myclass c = new myclass ();
C.ExecuteCommand ();
#Line Hidden
Console.writeline ("Show some text");
Console.writeline ("Show some text");
Console.writeline ("Show some text");
#LINE
C.ProcessCommand ();
C. close ();
}
} However, # line hidden instructions do not hide compiler errors. Of course, the compiler still compiles the code into the IL, and the code is still executed; the compiler is only forbidden to enter its content. The second C # new function involves an XML annotation, which is added according to the ECMA standard. C # now supports adding XML annotations to multi-line comments written in the "slash and asterisk" symbol (/ * / * /). The following XML comment is legal in the 2003 version of the C # compiler: / **
Comment
* / Further, for integrity considerations (but actually never recommended), programmers can mix and match the annotation style while still writing a valid XML annotation code. In this way, this annotation declaration is also legal: / **
Comment
* /
/// Implementation of the change of the 2003 version of the C # compiler and 2002 version also have a small difference. In some cases, these differences may result in codes that cannot be compiled or causing its operating mode to be larger in the way. The change of the "foreach" statement is now, the Foreach statement can dynamically check if there is an IDisposable interface in the data structure it iteratively. Previously, the compiler did not correct if the IDisposable interface exists unless the IEnumerator interface was implemented unless the type returned from getENUMERATOR. However, if this type is static for implementing IDisposable, the compiler will always call DISPOSE. In other words, if the iterative program type implements the enumerator design mode, but does not specifically implement the IEnumerator interface, the compiler will not call the Dispose method unless Iterator type is static for the Idisposable interface. Now, the compiler will call the Dispose method if the ITISPOSable interface is detected, whether or not the iterative program type implements the IEnumerator. In the example below, the Visual C # .NET 2002 compiler is not called the Dispose method, but the Visual C # .NET 2003 compiler calls the method: Abstract class base {
Public int current {get;}
Public bool movenext ();
}
Class Derived: Base, IDisposable
{
// Base and IDisposable implementation
}
Class myclass
{
Public base getenumerator ()
{
Return new deerived ();
}
} When the foreach statement uses iteration in an object collection, it will execute the GetEnumerator method and receive the DeriveD instance converted to the base type as its iterative program type. Of course, the Base type does not need to implement the IEnumerator interface in order to invoke its Current and MoveNext methods. In an earlier compiler, the DeriveD type DISPOSE method is not called because it does not implement IEnumerator, and class base is not static for implementing IDisposable. In the new compiler, the Dispose method is called because the compiler checks if there is an idisposable interface in the iterative program type of all foreach statements. Since the result of the getEnumerator call is a DeriveD type converted to the base type, and because the DeriveD type implements the IDisposable interface, the compiler dynamically checks if the IDisposable interface exists, which will result in calls to the Dispose method. Attribute declaration changes ECMA C # standards clearly prohibit creating access and setting functions for the appropriate properties. In fact, the C # compiler converts the attribute declaration to the acquisition and setting function so that the language that does not support attributes can also access the data. Therefore, the following code is invalid because the compiler generates a GET_PROP and SET_PROP method, and the two methods conflicts with the user declared method: public class myclass
{
Public int prop
{
get
{
}
set
{
}
}
/ / Is now an illegal function
Public int GET_PROP ()
{
}
/ / Is now an illegal function
Public void set_prop (int val) {
}
} Previously, the C # compiler allowed to create such functions, apparently this is a software error. The 2003 version of the C # compiler corrected this error. As the inevitable result of this compiler error correction, the C # compiler will no longer allow the explicit creation of acquisition and setting functions (if the attribute is defined as the result of the interface implementation). In the following example, the 2003 version of the C # compiler no longer allows explicit implementation IMYINTERFACE.GET_PROP and IMYINTERFACE.SET_PROP methods in the DeriveD class: Interface ImyInterface
{
Public int prop {get; set;}
}
Public Class Derived: ImyInterface
{
Public int prop
{
get
{
}
set
{
}
}
// illegal
Public Int iMyinterface.get_prop ()
{
}
// illegal
Public void iMyinterface.set_prop (int val)
{
}
} Other changes to the early version of the C # compiler allow for incompatibility to use properties. The 2003 version of the C # compiler has corrected these usage, so it is more in line with ECMA specifications. The first is to correct the C # compiler, not allowed to use the nameless parameters that are not declared in the property class declaration in its parameter list. For example, if an AuthorAttribute class is created using a private field named authorName, the following statement is allowed in the early versions of the C # compiler, but in the C # 2003 compiler, it will cause errors: [Authorname = "MicrosoftUser"]]
Public Class Myclass
{
} Second, ObsoleTeattribute can now be applied to operators so that programmers can make overloaded operator functions. Finally, the compiler previously generates an error for the location where the attributes that cannot be identified, and now only one warning is generated according to the requirements of the ECMA C # specification. In addition, the C # compiler previously accepted user-defined shift operator parameters (<< and >>), and these parameters are invalid according to ECMA C # specification. For example, the shift operator can be declared in the following ways, so that the type of package class is declared as the second operand: public class myclass
{
Public Static MyClass Operator << (INT I, MyClass C)
{
}
Public static void main ()
{
}
} According to the specification, if the arithmetic operator is overloaded to the left, the first parameter in the operator list of the binary operator must be a package type. Similarly, if the operator is reloaded to the right, the second parameter in the operand list of the binary operator must be a package type. The following code example demonstrates the correct declaration of the left shift operator: public class myclass
{
Public Static MyClass Operator << (MyClass C, INT i)
{
}
Public static void main ()
{
}
} Finally, several repairs for correcting compiler errors have also been added, including:
Correcting the explicit assignment algorithm so that the compiler is no longer reported to the code that meets the ECMA C # specification. Enumeration Types can now be converted to characters (see descriptions in the ECMA C # specification for details). The internal virtual warning has been deleted because the internal virtual function cannot be rewritten outside the program set. The small knot C # compiler achieves several functions in different ways, thereby obtaining higher performance than the previous version. But these improvements do not affect the compilation and execution of the code: When an iterative string element, the Foreach statement is now using the string indexer instead of an enumerator mode, which makes the performance better. Now, the C # compiler has strictly follow the ECMA C # specification in handling floating point operations and decimal mathematical operations. Several software errors have been fixed to optimize the control flow.
