| CATEGORII DOCUMENTE |
A member lookup is the process whereby the meaning of a name in the context of a type is determined. A member lookup may occur as part of evaluating a simple-name (7.5.2) or a member-access (7.5.4) in an expression.
A member lookup of a name N in a type T is processed as follows:
First, the set of all accessible (3.5) members named N declared in T and the base types (7.3.1) of T is constructed. Declarations that include an override modifier are excluded from the set. If no members named N exist and are accessible, then the lookup produces no match, and the following steps are not evaluated.
Next, members that are hidden by other members are removed from the set. For every member S.M in the set, where S is the type in which the member M is declared, the following rules are applied:
If M is a constant, field, property, event, type, or enumeration member, then all members declared in a base type of S are removed from the set.
If M is a method, then all non-method members declared in a base type of S are removed from the set, and all methods with the same signature as M declared in a base type of S are removed from the set.
Finally, having removed hidden members, the result of the lookup is determined:
If the set consists of a single non-method member, then this member is the result of the lookup.
Otherwise, if the set contains only methods, then this group of methods is the result of the lookup.
Otherwise, the lookup is ambiguous, and a compile-time error occurs (this situation can only occur for a member lookup in an interface that has multiple direct base interfaces).
For member lookups in types other than interfaces, and member lookups in interfaces that are strictly single-inheritance (each interface in the inheritance chain has exactly zero or one direct base interface), the effect of the lookup rules is simply that derived members hide base members with the same name or signature. Such single-inheritance lookups are never ambiguous. The ambiguities that can possibly arise from member lookups in multiple-inheritance interfaces are described in 13.2.5.
For purposes of member lookup, a type T is considered to have the following base types:
If T is object, then T has no base type.
If T is a value-type, the base type of T is the class type object.
If T is a class-type, the base types of T are the base classes of T, including the class type object.
If T is an interface-type, the base types of T are the base interfaces of T and the class type object.
If T is an array-type, the base types of T are the class types System.Array and object.
If T is a delegate-type, the base types of T are the class types System.Delegate and object.
Function members are members that contain executable statements. Function members are always members of types and cannot be members of namespaces. C# defines the following categories of function members:
Methods
Properties
Events
Indexers
User-defined operators
Instance constructors
Static constructors
Destructors
The statements contained in function members are executed through function member invocations. The actual syntax for writing a function member invocation depends on the particular function member category. However, all function member invocations are expressions, allow arguments to be passed to the function member, and allow the function member to compute and return a result.
The argument list (7.4.1) of a function member invocation provides actual values or variable references for the parameters of the function member.
Invocations of constructors, methods, indexers, and operators employ overload resolution to determine which of a candidate set of function members to invoke. This process is described in 7.4.2.
Once a particular function member has been identified at compile-time, possibly through overload resolution, the actual run-time process of invoking the function member is described in 7.4.3.
The following table summarizes the processing that takes place in constructs involving the five categories of function members. In the table, e, x, y, and value indicate expressions classified as variables or values, T indicates an expression classified as a type, F is the simple name of a method, and P is the simple name of a property.
|
Construct |
Example |
Description |
|
Constructor invocation |
new T(x, y) |
Overload resolution is applied to select the best constructor in the class or struct T. The constructor is invoked with the argument list (x, y). |
|
Method invocation |
F(x, y) |
Overload resolution is applied to select the best method F in the containing class or struct. The method is invoked with the argument list (x, y). If the method is not static, the instance expression is this. |
|
T.F(x, y) |
Overload resolution is applied to select the best method F in the class or struct T. An error occurs if the method is not static. The method is invoked with the argument list (x, y). |
|
|
e.F(x, y) |
Overload resolution is applied to select the best method F in the class, struct, or interface given by the type of e. An error occurs if the method is static. The method is invoked with the instance expression e and the argument list (x, y). |
|
|
Property access |
P |
The get accessor of the property P in the containing class or struct is invoked. An error occurs if P is write-only. If P is not static, the instance expression is this. |
|
P = value |
The set accessor of the property P in the containing class or struct is invoked with the argument list (value). An error occurs if P is read-only. If P is not static, the instance expression is this. |
|
|
T.P |
The get accessor of the property P in the class or struct T is invoked. An error occurs if P is not static or if P is write-only. |
|
|
T.P = value |
The set accessor of the property P in the class or struct T is invoked with the argument list (value). An error occurs if P is not static or if P is read-only. |
|
|
e.P |
The get accessor of the property P in the class, struct, or interface given by the type of e is invoked with the instance expression e. An error occurs if P is static or if P is write-only. |
|
|
e.P = value |
The set accessor of the property P in the class, struct, or interface given by the type of e is invoked with the instance expression e and the argument list (value). An error occurs if P is static or if P is read-only. |
|
|
Event access |
E += value |
The add accessor of the event E in the containing class or struct is invoked. If E is not static, the instance expression is this. |
|
E -= value |
The remove accessor of the event E in the containing class or struct is invoked. If E is not static, the instance expression is this. |
|
|
T.E += value |
The add accessor of the event E in the class or struct T is invoked. An error occurs if E is not static. |
|
|
T.E -= value |
The remove accessor of the event E in the class or struct T is invoked. An error occurs if E is not static. |
|
|
e.E += value |
The add accessor of the event E in the class, struct, or interface given by the type of e is invoked with the instance expression e. An error occurs if E is static. |
|
|
e.E -= value |
The remove accessor of the event E in the class, struct, or interface given by the type of e is invoked with the instance expression e. An error occurs if E is static. |
|
|
Indexer access |
e[x, y] |
Overload resolution is applied to select the best indexer in the class, struct, or interface given by the type of e. The get accessor of the indexer is invoked with the instance expression e and the argument list (x, y). An error occurs if the indexer is write-only. |
|
e[x, y] = value |
Overload resolution is applied to select the best indexer in the class, struct, or interface given by the type of e. The set accessor of the indexer is invoked with the instance expression e and the argument list (x, y, value). An error occurs if the indexer is read-only. |
|
|
Operator invocation |
-x |
Overload resolution is applied to select the best unary operator in the class or struct given by the type of x. The selected operator is invoked with the argument list (x). |
|
x + y |
Overload resolution is applied to select the best binary operator in the classes or structs given by the types of x and y. The selected operator is invoked with the argument list (x, y). |
Every function member invocation includes an argument list which provides actual values or variable references for the parameters of the function member. The syntax for specifying the argument list of a function member invocation depends on the function member category:
For methods, instance constructors, and delegates, the arguments are specified as an argument-list, as described below.
For properties, the argument list is empty when invoking the get accessor, and consists of the expression specified as the right operand of the assignment operator when invoking the set accessor.
For events, the argument list consists of the expression specified as the right operand of the += or -= operator.
For indexers, the argument list consists of the expressions specified between the square brackets in the indexer access. When invoking the set accessor, the argument list additionally includes the expression specified as the right operand of the assignment operator.
For user-defined operators, the argument list consists of the single operand of the unary operator or the two operands of the binary operator.
The arguments of volatile fields (10.4.3), properties (10.6), events (10.7), indexers (10.8), and user-defined operators (10.9) are always passed as value parameters (10.5.1.1). Reference and output parameters are not supported for these categories of function members.
The arguments of a method, instance constructor, or delegate invocation are specified as an argument-list:
argument-list:
argument
argument-list , argument
argument:
expression
ref variable-reference
out variable-reference
An argument-list consists of zero or more arguments, separated by commas. Each argument can take one of the following forms:
An expression, indicating that the argument is passed as a value parameter (10.5.1.1).
The keyword ref followed by a variable-reference (5.4), indicating that the argument is passed as a reference parameter (10.5.1.2). A variable must be definitely assigned (5.3) before it can be passed as a reference parameter.
The keyword out followed by a variable-reference (5.4), indicating that the argument is passed as an output parameter (10.5.1.3). A variable is considered definitely assigned (5.3) following a function member invocation in which the variable is passed as an output parameter.
During the run-time processing of a function member invocation (7.4.3), the expressions or variable references of an argument list are evaluated in order, from left to right, as follows:
For a value parameter, the argument expression is evaluated and an implicit conversion (6.1) to the corresponding parameter type is performed. The resulting value becomes the initial value of the value parameter in the function member invocation.
For a reference or output parameter, the variable reference is evaluated and the resulting storage location becomes the storage location represented by the parameter in the function member invocation. If the variable reference given as a reference or output parameter is an array element of a reference-type, a run-time check is performed to ensure that element type of the array is identical to the type of the parameter. If this check fails, a System.ArrayTypeMismatchException is thrown.
Methods, indexers, and instance constructors may declare their right-most parameter to be a parameter array (10.5.1.4). Such function members are invoked either in their normal form or in their expanded form depending on which is applicable (7.4.2.1):
When a function member with a parameter array is invoked in its normal form, the argument given for the parameter array must be a single expression of a type that is implicitly convertible (6.1) to the parameter array type. In this case, the parameter array acts precisely like a value parameter.
When a function member with a parameter array is invoked in its expanded form, the invocation must specify zero or more arguments for the parameter array, where each argument is an expression of a type that is implicitly convertible (6.1) to the element type of the parameter array. In this case, the invocation creates an instance of the parameter array type with a length corresponding to the number of arguments, initializes the elements of the array instance with the given argument values, and uses the newly created array instance as the actual argument.
The expressions of an argument list are always evaluated in the order they are written. Thus, the example
class
Test
, y = , z = ', x, y, z);
}
static void
}
produces the output
x = 0, y = 1, z = 2
The array co-variance rules (12.5) permit a value of an array type A[] to be a reference to an instance of an array type B[], provided an implicit reference conversion exists from B to A. Because of these rules, when an array element of a reference-type is passed as a reference or output parameter, a run-time check is required to ensure that the actual element type of the array is identical to that of the parameter. In the example
class
Test
static void Main()
}
the second invocation of F causes a System.ArrayTypeMismatchException to be thrown because the actual element type of b is string and not object.
When a function member with a parameter array is invoked in its expanded form, the invocation is processed exactly as if an array creation expression with an array initializer (7.5.10.2) was inserted around the expanded parameters. For example, given the declaration
void F(int x, int y, params object[] args);
the following invocations of the expanded form of the method
F(10,
20);
F(10, 20, 30, 40);
F(10, 20, 1, 'hello', 3.0);
correspond exactly to
F(10,
20, new object[] );
F(10, 20, new object[] );
F(10, 20, new object[] );
Note in particular that an empty array is created when there are zero arguments given for the parameter array.
Overload resolution is a compile-time mechanism for selecting the best function member to invoke given an argument list and a set of candidate function members. Overload resolution selects the function member to invoke in the following distinct contexts within C#:
Invocation of a method named in an invocation-expression (7.5.5).
Invocation of an instance constructor named in an object-creation-expression (7.5.10.1).
Invocation of an indexer accessor through an element-access (7.5.6).
Invocation of a predefined or user-defined operator referenced in an expression (7.2.3 and 7.2.4).
Each of these contexts defines the set of candidate function members and the list of arguments in its own unique way. However, once the candidate function members and the argument list have been identified, the selection of the best function member is the same in all cases:
First, the set of candidate function members is reduced to those function members that are applicable with respect to the given argument list (7.4.2.1). If this reduced set is empty, an error occurs.
Then, given the set of applicable candidate function members, the best function member in that set is located. If the set contains only one function member, then that function member is the best function member. Otherwise, the best function member is the one function member that is better than all other function members with respect to the given argument list, provided that each function member is compared to all other function members using the rules in 7.4.2.2. If there is not exactly one function member that is better than all other function members, then the function member invocation is ambiguous and an error occurs.
The following sections define the exact meanings of the terms applicable function member and better function member.
A function member is said to be an applicable function member with respect to an argument list A when all of the following are true:
The number of arguments in A is identical to the number of parameters in the function member declaration.
For each argument in A, the parameter passing mode of the argument is identical to the parameter passing mode of the corresponding parameter, and
for a value parameter or a parameter array, an implicit conversion (6.1) exists from the type of the argument to the type of the corresponding parameter, or
for a ref or out parameter, the type of the argument is identical to the type of the corresponding parameter.
For a function member that includes a parameter array, if the function member is applicable by the above rules, it is said to be applicable in its normal form. If a function member that includes a parameter array is not applicable in its normal form, the function member may instead be applicable in its expanded form:
The expanded form is constructed by replacing the parameter array in the function member declaration with zero or more value parameters of the element type of the parameter array such that the number of arguments in the argument list A matches the total number of parameters. If A has fewer arguments than the number of fixed parameters in the function member declaration, the expanded form of the function member cannot be constructed and is thus not applicable.
If the class, struct, or interface in which the function member is declared already contains another applicable function member with the same signature as the expanded form, the expanded form is not applicable.
Otherwise, the expanded form is applicable if for each argument in A the parameter passing mode of the argument is identical to the parameter passing mode of the corresponding parameter, and
for a fixed value parameter or a value parameter created by the expansion, an implicit conversion (6.1) exists from the type of the argument to the type of the corresponding parameter, or
for a ref or out parameter, the type of the argument is identical to the type of the corresponding parameter.
Given an argument list A with a set of argument types A1, A2, , AN and two applicable function members MP and MQ with parameter types P1, P2, , PN and Q1, Q2, , QN, MP is defined to be a better function member than MQ if
for each argument, the implicit conversion from AX to PX is not worse than the implicit conversion from AX to QX, and
for at least one argument, the conversion from AX to PX is better than the conversion from AX to QX.
When performing this evaluation, if MP or MQ is applicable in its expanded form, then PX or QX refers to a parameter in the expanded form of the parameter list.
Given an implicit conversion C1 that converts from a type S to a type T1, and an implicit conversion C2 that converts from a type S to a type T2, the better conversion of the two conversions is determined as follows:
If T1 and T2 are the same type, neither conversion is better.
If S is T1, C1 is the better conversion.
If S is T2, C2 is the better conversion.
If an implicit conversion from T1 to T2 exists, and no implicit conversion from T2 to T1 exists, C1 is the better conversion.
If an implicit conversion from T2 to T1 exists, and no implicit conversion from T1 to T2 exists, C2 is the better conversion.
If T1 is sbyte and T2 is byte, ushort, uint, or ulong, C1 is the better conversion.
If T2 is sbyte and T1 is byte, ushort, uint, or ulong, C2 is the better conversion.
If T1 is short and T2 is ushort, uint, or ulong, C1 is the better conversion.
If T2 is short and T1 is ushort, uint, or ulong, C2 is the better conversion.
If T1 is int and T2 is uint, or ulong, C1 is the better conversion.
If T2 is int and T1 is uint, or ulong, C2 is the better conversion.
If T1 is long and T2 is ulong, C1 is the better conversion.
If T2 is long and T1 is ulong, C2 is the better conversion.
Otherwise, neither conversion is better.
If an implicit conversion C1 is defined by these rules to be a better conversion than an implicit conversion C2, then it is also the case that C2 is a worse conversion than C1.
This section describes the process that takes place at run-time to invoke a particular function member. It is assumed that a compile-time process has already determined the particular member to invoke, possibly by applying overload resolution to a set of candidate function members.
For purposes of describing the invocation process, function members are divided into two categories:
Static function members. These are static methods, constructors, static property accessors, and user-defined operators. Static function members are always non-virtual.
Instance function members. These are instance methods, instance property accessors, and indexer accessors. Instance function members are either non-virtual or virtual, and are always invoked on a particular instance. The instance is computed by an instance expression, and it becomes accessible within the function member as this (7.5.7).
The run-time processing of a function member invocation consists of the following steps, where M is the function member and, if M is an instance member, E is the instance expression:
If M is a static function member:
The argument list is evaluated as described in 7.4.1.
M is invoked.
If M is an instance function member declared in a value-type:
E is evaluated. If this evaluation causes an exception, then no further steps are executed.
If E is not classified as a variable, then a temporary local variable of E's type is created and the value of E is assigned to that variable. E is then reclassified as a reference to that temporary local variable. The temporary variable is accessible as this within M, but not in any other way. Thus, only when E is a true variable is it possible for the caller to observe the changes that M makes to this.
The argument list is evaluated as described in 7.4.1.
M is invoked. The variable referenced by E becomes the variable referenced by this.
If M is an instance function member declared in a reference-type:
E is evaluated. If this evaluation causes an exception, then no further steps are executed.
The argument list is evaluated as described in 7.4.1.
If the type of E is a value-type, a boxing conversion (4.3.1) is performed to convert E to type object, and E is considered to be of type object in the following steps.
The value of E is checked to be valid. If the value of E is null, a System.NullReferenceException is thrown and no further steps are executed.
The function member implementation to invoke is determined: If M is a non-virtual function member, then M is the function member implementation to invoke. Otherwise, M is a virtual function member and the function member implementation to invoke is determined through virtual function member lookup (7.4.4) or interface function member lookup (7.4.5).
The function member implementation determined in the step above is invoked. The object referenced by E becomes the object referenced by this.
A function member implemented in a value-type can be invoked through a boxed instance of that value-type in the following situations:
When the function member is an override of a method inherited from type object and is invoked through an instance expression of type object.
When the function member is an implementation of an interface function member and is invoked through an instance expression of an interface-type.
When the function member is invoked through a delegate.
In these situations, the boxed instance is considered to contain a variable of the value-type, and this variable becomes the variable referenced by this within the function member invocation. This in particular means that when a function member is invoked on a boxed instance, it is possible for the function member to modify the value contained in the boxed instance.
Issue
We need to write this section.
Issue
We need to write this section.
|
Politica de confidentialitate | Termeni si conditii de utilizare |
Vizualizari: 1039
Importanta: 
Termeni si conditii de utilizare | Contact
© SCRIGROUP 2024 . All rights reserved
