Batch 62 (#2834)
This commit is contained in:
parent
da452002c3
commit
892af9016b
|
@ -790,12 +790,13 @@ class Test
|
|||
}
|
||||
```
|
||||
creates an instance of class `A` and an instance of class `B`. These objects become eligible for garbage collection when the variable `b` is assigned the value `null`, since after this time it is impossible for any user-written code to access them. The output could be either
|
||||
```
|
||||
|
||||
```console
|
||||
Destruct instance of A
|
||||
Destruct instance of B
|
||||
```
|
||||
or
|
||||
```
|
||||
```console
|
||||
Destruct instance of B
|
||||
Destruct instance of A
|
||||
```
|
||||
|
@ -851,7 +852,7 @@ class Test
|
|||
```
|
||||
|
||||
In the above program, if the garbage collector chooses to run the destructor of `A` before the destructor of `B`, then the output of this program might be:
|
||||
```
|
||||
```console
|
||||
Destruct instance of A
|
||||
Destruct instance of B
|
||||
A.F
|
||||
|
|
|
@ -1212,7 +1212,7 @@ class Test
|
|||
}
|
||||
```
|
||||
a class `A` defines a read-only property `P`, thus reserving signatures for `get_P` and `set_P` methods. A class `B` derives from `A` and hides both of these reserved signatures. The example produces the output:
|
||||
```
|
||||
```console
|
||||
123
|
||||
123
|
||||
456
|
||||
|
@ -1528,7 +1528,7 @@ class Test
|
|||
}
|
||||
```
|
||||
produces the output:
|
||||
```
|
||||
```console
|
||||
result = 143
|
||||
```
|
||||
|
||||
|
@ -1552,7 +1552,7 @@ class Test
|
|||
}
|
||||
```
|
||||
produces the output
|
||||
```
|
||||
```console
|
||||
b = False, i = 0
|
||||
```
|
||||
because `b` and `i` are both automatically initialized to default values.
|
||||
|
@ -1578,7 +1578,7 @@ class Test
|
|||
}
|
||||
```
|
||||
produces the output
|
||||
```
|
||||
```console
|
||||
x = 1.4142135623731, i = 100, s = Hello
|
||||
```
|
||||
because an assignment to `x` occurs when static field initializers execute and assignments to `i` and `s` occur when the instance field initializers execute.
|
||||
|
@ -1600,7 +1600,7 @@ class Test
|
|||
}
|
||||
```
|
||||
exhibits this behavior. Despite the circular definitions of a and b, the program is valid. It results in the output
|
||||
```
|
||||
```console
|
||||
a = 1, b = 2
|
||||
```
|
||||
because the static fields `a` and `b` are initialized to `0` (the default value for `int`) before their initializers are executed. When the initializer for `a` runs, the value of `b` is zero, and so `a` is initialized to `1`. When the initializer for `b` runs, the value of `a` is already `1`, and so `b` is initialized to `2`.
|
||||
|
@ -1634,13 +1634,13 @@ class B
|
|||
}
|
||||
```
|
||||
might produce either the output:
|
||||
```
|
||||
```console
|
||||
Init A
|
||||
Init B
|
||||
1 1
|
||||
```
|
||||
or the output:
|
||||
```
|
||||
```console
|
||||
Init B
|
||||
Init A
|
||||
1 1
|
||||
|
@ -1676,7 +1676,7 @@ class B
|
|||
}
|
||||
```
|
||||
the output must be:
|
||||
```
|
||||
```console
|
||||
Init B
|
||||
Init A
|
||||
1 1
|
||||
|
@ -1906,7 +1906,7 @@ class Test
|
|||
}
|
||||
```
|
||||
produces the output
|
||||
```
|
||||
```console
|
||||
i = 2, j = 1
|
||||
```
|
||||
|
||||
|
@ -1970,7 +1970,7 @@ class Test
|
|||
```
|
||||
|
||||
The example produces the output:
|
||||
```
|
||||
```console
|
||||
c:\Windows\System\
|
||||
hello.txt
|
||||
```
|
||||
|
@ -2010,7 +2010,7 @@ class Test
|
|||
}
|
||||
```
|
||||
produces the output
|
||||
```
|
||||
```console
|
||||
Array contains 3 elements: 1 2 3
|
||||
Array contains 4 elements: 10 20 30 40
|
||||
Array contains 0 elements:
|
||||
|
@ -2052,7 +2052,7 @@ class Test
|
|||
}
|
||||
```
|
||||
produces the output
|
||||
```
|
||||
```console
|
||||
F();
|
||||
F(object[]);
|
||||
F(object,object);
|
||||
|
@ -2089,7 +2089,7 @@ class Test
|
|||
}
|
||||
```
|
||||
produces the output
|
||||
```
|
||||
```console
|
||||
System.Int32 System.String System.Double
|
||||
System.Object[]
|
||||
System.Object[]
|
||||
|
@ -2160,7 +2160,7 @@ class Test
|
|||
```
|
||||
|
||||
In the example, `A` introduces a non-virtual method `F` and a virtual method `G`. The class `B` introduces a new non-virtual method `F`, thus hiding the inherited `F`, and also overrides the inherited method `G`. The example produces the output:
|
||||
```
|
||||
```console
|
||||
A.F
|
||||
B.F
|
||||
B.G
|
||||
|
@ -2208,7 +2208,7 @@ class Test
|
|||
}
|
||||
```
|
||||
the `C` and `D` classes contain two virtual methods with the same signature: The one introduced by `A` and the one introduced by `C`. The method introduced by `C` hides the method inherited from `A`. Thus, the override declaration in `D` overrides the method introduced by `C`, and it is not possible for `D` to override the method introduced by `A`. The example produces the output:
|
||||
```
|
||||
```console
|
||||
B.F
|
||||
B.F
|
||||
D.F
|
||||
|
@ -3850,7 +3850,7 @@ class B: A
|
|||
}
|
||||
```
|
||||
when `new B()` is used to create an instance of `B`, the following output is produced:
|
||||
```
|
||||
```console
|
||||
x = 1, y = 0
|
||||
```
|
||||
|
||||
|
@ -4076,7 +4076,7 @@ class B
|
|||
}
|
||||
```
|
||||
must produce the output:
|
||||
```
|
||||
```console
|
||||
Init A
|
||||
A.F
|
||||
Init B
|
||||
|
@ -4111,7 +4111,7 @@ class B
|
|||
}
|
||||
```
|
||||
produces the output
|
||||
```
|
||||
```console
|
||||
X = 1, Y = 2
|
||||
```
|
||||
|
||||
|
|
|
@ -236,7 +236,7 @@ Immediately prior to the execution of the final statement, `cd3 -= cd1;`, the de
|
|||
|
||||
The output produced is:
|
||||
|
||||
```
|
||||
```console
|
||||
C.M1: -1
|
||||
C.M2: -2
|
||||
C.M1: 10
|
||||
|
|
|
@ -178,7 +178,7 @@ This tag allows including information from an XML document that is external to t
|
|||
|
||||
__Syntax:__
|
||||
|
||||
```
|
||||
```xml
|
||||
<include file="filename" path="xpath" />
|
||||
```
|
||||
|
||||
|
|
|
@ -154,7 +154,7 @@ class Test
|
|||
|
||||
prints out the enum member names and their associated values. The output is:
|
||||
|
||||
```
|
||||
```console
|
||||
Red = 0
|
||||
Green = 10
|
||||
Blue = 11
|
||||
|
|
|
@ -479,7 +479,7 @@ class Test
|
|||
}
|
||||
```
|
||||
produces the output
|
||||
```
|
||||
```console
|
||||
x = 0, y = 1, z = 2
|
||||
x = 4, y = -1, z = 3
|
||||
```
|
||||
|
@ -1201,7 +1201,7 @@ class A
|
|||
#### Grammar ambiguities
|
||||
|
||||
The productions for *simple_name* ([Simple names](expressions.md#simple-names)) and *member_access* ([Member access](expressions.md#member-access)) can give rise to ambiguities in the grammar for expressions. For example, the statement:
|
||||
```
|
||||
```csharp
|
||||
F(G<A,B>(7));
|
||||
```
|
||||
could be interpreted as a call to `F` with two arguments, `G < A` and `B > (7)`. Alternatively, it could be interpreted as a call to `F` with one argument, which is a call to a generic method `G` with two type arguments and one regular argument.
|
||||
|
@ -1402,7 +1402,7 @@ namespace N2
|
|||
```
|
||||
|
||||
The output of this example is:
|
||||
```
|
||||
```console
|
||||
E.F(1)
|
||||
D.G(2)
|
||||
C.H(3)
|
||||
|
@ -2135,7 +2135,7 @@ class Test
|
|||
}
|
||||
```
|
||||
produces the following output:
|
||||
```
|
||||
```console
|
||||
System.Int32
|
||||
System.Int32
|
||||
System.String
|
||||
|
@ -3183,7 +3183,7 @@ The operators compare the operands according to the rules of the IEEE 754 standa
|
|||
* If either operand is NaN, the result is `false` for all operators except `!=`, for which the result is `true`. For any two operands, `x != y` always produces the same result as `!(x == y)`. However, when one or both operands are NaN, the `<`, `>`, `<=`, and `>=` operators do not produce the same results as the logical negation of the opposite operator. For example, if either of `x` and `y` is NaN, then `x < y` is `false`, but `!(x >= y)` is `true`.
|
||||
* When neither operand is NaN, the operators compare the values of the two floating-point operands with respect to the ordering
|
||||
|
||||
```
|
||||
```csharp
|
||||
-inf < -max < ... < -min < -0.0 == +0.0 < +min < ... < +max < +inf
|
||||
```
|
||||
|
||||
|
@ -3286,7 +3286,7 @@ class Test
|
|||
}
|
||||
```
|
||||
produces the output
|
||||
```
|
||||
```console
|
||||
True
|
||||
False
|
||||
False
|
||||
|
@ -3830,7 +3830,7 @@ class Test
|
|||
}
|
||||
```
|
||||
the local variable `x` is captured by the anonymous function, and the lifetime of `x` is extended at least until the delegate returned from `F` becomes eligible for garbage collection (which doesn't happen until the very end of the program). Since each invocation of the anonymous function operates on the same instance of `x`, the output of the example is:
|
||||
```
|
||||
```console
|
||||
1
|
||||
2
|
||||
3
|
||||
|
@ -3889,7 +3889,7 @@ class Test
|
|||
}
|
||||
```
|
||||
produces the output:
|
||||
```
|
||||
```console
|
||||
1
|
||||
3
|
||||
5
|
||||
|
@ -3908,7 +3908,7 @@ static D[] F() {
|
|||
}
|
||||
```
|
||||
the output is:
|
||||
```
|
||||
```console
|
||||
5
|
||||
5
|
||||
5
|
||||
|
@ -3926,7 +3926,7 @@ static D[] F() {
|
|||
}
|
||||
```
|
||||
only one instance of the iteration variable is captured, which produces the output:
|
||||
```
|
||||
```console
|
||||
3
|
||||
3
|
||||
3
|
||||
|
@ -3945,7 +3945,7 @@ static D[] F() {
|
|||
}
|
||||
```
|
||||
the three delegates capture the same instance of `x` but separate instances of `y`, and the output is:
|
||||
```
|
||||
```console
|
||||
1 1
|
||||
2 1
|
||||
3 1
|
||||
|
@ -3973,7 +3973,7 @@ class Test
|
|||
}
|
||||
```
|
||||
the two anonymous functions capture the same instance of the local variable `x`, and they can thus "communicate" through that variable. The output of the example is:
|
||||
```
|
||||
```console
|
||||
5
|
||||
10
|
||||
```
|
||||
|
@ -4131,11 +4131,11 @@ from x in ( e ) . Cast < T > ( )
|
|||
```
|
||||
|
||||
A `join` clause that explicitly specifies a range variable type
|
||||
```
|
||||
```csharp
|
||||
join T x in e on k1 equals k2
|
||||
```
|
||||
is translated into
|
||||
```
|
||||
```csharp
|
||||
join x in ( e ) . Cast < T > ( ) on k1 equals k2
|
||||
```
|
||||
|
||||
|
|
|
@ -28,11 +28,11 @@ class Hello
|
|||
```
|
||||
|
||||
C# source files typically have the file extension `.cs`. Assuming that the "Hello, World" program is stored in the file `hello.cs`, the program can be compiled with the Microsoft C# compiler using the command line
|
||||
```
|
||||
```console
|
||||
csc hello.cs
|
||||
```
|
||||
which produces an executable assembly named `hello.exe`. The output produced by this application when it is run is
|
||||
```
|
||||
```console
|
||||
Hello, World
|
||||
```
|
||||
|
||||
|
@ -83,7 +83,7 @@ namespace Acme.Collections
|
|||
```
|
||||
declares a class named `Stack` in a namespace called `Acme.Collections`. The fully qualified name of this class is `Acme.Collections.Stack`. The class contains several members: a field named `top`, two methods named `Push` and `Pop`, and a nested class named `Entry`. The `Entry` class further contains three members: a field named `next`, a field named `data`, and a constructor. Assuming that the source code of the example is stored in the file `acme.cs`, the command line
|
||||
|
||||
```
|
||||
```console
|
||||
csc /t:library acme.cs
|
||||
```
|
||||
compiles the example as a library (code without a `Main` entry point) and produces an assembly named `acme.dll`.
|
||||
|
@ -111,12 +111,12 @@ class Test
|
|||
```
|
||||
If the program is stored in the file `test.cs`, when `test.cs` is compiled, the `acme.dll` assembly can be referenced using the compiler's `/r` option:
|
||||
|
||||
```
|
||||
```console
|
||||
csc /r:acme.dll test.cs
|
||||
```
|
||||
This creates an executable assembly named `test.exe`, which, when run, produces the output:
|
||||
|
||||
```
|
||||
```console
|
||||
100
|
||||
10
|
||||
1
|
||||
|
|
|
@ -1107,7 +1107,7 @@ class Hello
|
|||
}
|
||||
```
|
||||
results in the output:
|
||||
```
|
||||
```console
|
||||
hello,
|
||||
#if Debug
|
||||
world
|
||||
|
|
|
@ -823,7 +823,7 @@ class Test
|
|||
}
|
||||
```
|
||||
The output produced is as follows:
|
||||
```csharp
|
||||
```console
|
||||
1.2 2.3 3.4 4.5 5.6 6.7 7.8 8.9
|
||||
```
|
||||
|
||||
|
@ -882,7 +882,7 @@ class Test
|
|||
the `finally` blocks associated with two `try` statements are executed before control is transferred to the target of the jump statement.
|
||||
|
||||
The output produced is as follows:
|
||||
```
|
||||
```console
|
||||
Before break
|
||||
Innermost finally block
|
||||
Outermost finally block
|
||||
|
@ -1130,13 +1130,13 @@ class Test
|
|||
}
|
||||
```
|
||||
the method `F` catches an exception, writes some diagnostic information to the console, alters the exception variable, and re-throws the exception. The exception that is re-thrown is the original exception, so the output produced is:
|
||||
```
|
||||
```console
|
||||
Exception in F: G
|
||||
Exception in Main: G
|
||||
```
|
||||
|
||||
If the first catch block had thrown `e` instead of rethrowing the current exception, the output produced would be as follows:
|
||||
```
|
||||
```console
|
||||
Exception in F: G
|
||||
Exception in Main: F
|
||||
```
|
||||
|
|
|
@ -229,7 +229,7 @@ class Program
|
|||
```
|
||||
|
||||
The output of the program is:
|
||||
```
|
||||
```console
|
||||
1
|
||||
2
|
||||
3
|
||||
|
@ -278,7 +278,7 @@ class Program
|
|||
```
|
||||
|
||||
The first call to `Increment` modifies the value in the variable `x`. This is not equivalent to the second call to `Increment`, which modifies the value in a boxed copy of `x`. Thus, the output of the program is:
|
||||
```
|
||||
```console
|
||||
0
|
||||
1
|
||||
1
|
||||
|
|
|
@ -619,7 +619,7 @@ class Test
|
|||
|
||||
which produces the output:
|
||||
|
||||
```
|
||||
```console
|
||||
p - q = -14
|
||||
q - p = 14
|
||||
```
|
||||
|
@ -795,7 +795,7 @@ class Test
|
|||
|
||||
which produces the output:
|
||||
|
||||
```
|
||||
```console
|
||||
[0,0,0] = 0 [0,0,1] = 1 [0,0,2] = 2 [0,0,3] = 3
|
||||
[0,1,0] = 4 [0,1,1] = 5 [0,1,2] = 6 [0,1,3] = 7
|
||||
[0,2,0] = 8 [0,2,1] = 9 [0,2,2] = 10 [0,2,3] = 11
|
||||
|
|
Loading…
Reference in a new issue