Заглавная страница Избранные статьи Случайная статья Познавательные статьи Новые добавления Обратная связь FAQ Написать работу КАТЕГОРИИ: АрхеологияБиология Генетика География Информатика История Логика Маркетинг Математика Менеджмент Механика Педагогика Религия Социология Технологии Физика Философия Финансы Химия Экология ТОП 10 на сайте Приготовление дезинфицирующих растворов различной концентрацииТехника нижней прямой подачи мяча. Франко-прусская война (причины и последствия) Организация работы процедурного кабинета Смысловое и механическое запоминание, их место и роль в усвоении знаний Коммуникативные барьеры и пути их преодоления Обработка изделий медицинского назначения многократного применения Образцы текста публицистического стиля Четыре типа изменения баланса Задачи с ответами для Всероссийской олимпиады по праву Мы поможем в написании ваших работ! ЗНАЕТЕ ЛИ ВЫ?
Влияние общества на человека
Приготовление дезинфицирующих растворов различной концентрации Практические работы по географии для 6 класса Организация работы процедурного кабинета Изменения в неживой природе осенью Уборка процедурного кабинета Сольфеджио. Все правила по сольфеджио Балочные системы. Определение реакций опор и моментов защемления |
Candidate user-defined operatorsСодержание книги
Поиск на нашем сайте
Given a type T and an operation operator op(A), where op is an overloadable operator and A is an argument list, the set of candidate user-defined operators provided by T for operator op(A) is determined as follows: · Determine the type T0. If T is a nullable type, T0 is its underlying type, otherwise T0 is equal to T. · For all operator op declarations in T0 and all lifted forms of such operators, if at least one operator is applicable (§7.5.3.1) with respect to the argument list A, then the set of candidate operators consists of all such applicable operators in T0. · Otherwise, if T0 is object, the set of candidate operators is empty. · Otherwise, the set of candidate operators provided by T0 is the set of candidate operators provided by the direct base class of T0, or the effective base class of T0 if T0 is a type parameter. Numeric promotions Numeric promotion consists of automatically performing certain implicit conversions of the operands of the predefined unary and binary numeric operators. Numeric promotion is not a distinct mechanism, but rather an effect of applying overload resolution to the predefined operators. Numeric promotion specifically does not affect evaluation of user-defined operators, although user-defined operators can be implemented to exhibit similar effects. As an example of numeric promotion, consider the predefined implementations of the binary * operator: int operator *(int x, int y); When overload resolution rules (§7.5.3) are applied to this set of operators, the effect is to select the first of the operators for which implicit conversions exist from the operand types. For example, for the operation b * s, where b is a byte and s is a short, overload resolution selects operator *(int, int) as the best operator. Thus, the effect is that b and s are converted to int, and the type of the result is int. Likewise, for the operation i * d, where i is an int and d is a double, overload resolution selects operator *(double, double) as the best operator. Unary numeric promotions Unary numeric promotion occurs for the operands of the predefined +, –, and ~ unary operators. Unary numeric promotion simply consists of converting operands of type sbyte, byte, short, ushort, or char to type int. Additionally, for the unary – operator, unary numeric promotion converts operands of type uint to type long. Binary numeric promotions Binary numeric promotion occurs for the operands of the predefined +, –, *, /, %, &, |, ^, ==,!=, >, <, >=, and <= binary operators. Binary numeric promotion implicitly converts both operands to a common type which, in case of the non-relational operators, also becomes the result type of the operation. Binary numeric promotion consists of applying the following rules, in the order they appear here: · If either operand is of type decimal, the other operand is converted to type decimal, or a binding-time error occurs if the other operand is of type float or double. · Otherwise, if either operand is of type double, the other operand is converted to type double. · Otherwise, if either operand is of type float, the other operand is converted to type float. · Otherwise, if either operand is of type ulong, the other operand is converted to type ulong, or a binding-time error occurs if the other operand is of type sbyte, short, int, or long. · Otherwise, if either operand is of type long, the other operand is converted to type long. · Otherwise, if either operand is of type uint and the other operand is of type sbyte, short, or int, both operands are converted to type long. · Otherwise, if either operand is of type uint, the other operand is converted to type uint. · Otherwise, both operands are converted to type int. Note that the first rule disallows any operations that mix the decimal type with the double and float types. The rule follows from the fact that there are no implicit conversions between the decimal type and the double and float types. Also note that it is not possible for an operand to be of type ulong when the other operand is of a signed integral type. The reason is that no integral type exists that can represent the full range of ulong as well as the signed integral types. In both of the above cases, a cast expression can be used to explicitly convert one operand to a type that is compatible with the other operand. In the example decimal AddPercent(decimal x, double percent) { a binding-time error occurs because a decimal cannot be multiplied by a double. The error is resolved by explicitly converting the second operand to decimal, as follows: decimal AddPercent(decimal x, double percent) { Lifted operators Lifted operators permit predefined and user-defined operators that operate on non-nullable value types to also be used with nullable forms of those types. Lifted operators are constructed from predefined and user-defined operators that meet certain requirements, as described in the following: · For the unary operators + ++ - --! ~ a lifted form of an operator exists if the operand and result types are both non-nullable value types. The lifted form is constructed by adding a single? modifier to the operand and result types. The lifted operator produces a null value if the operand is null. Otherwise, the lifted operator unwraps the operand, applies the underlying operator, and wraps the result. · For the binary operators + - * / % & | ^ << >> a lifted form of an operator exists if the operand and result types are all non-nullable value types. The lifted form is constructed by adding a single? modifier to each operand and result type. The lifted operator produces a null value if one or both operands are null (an exception being the & and | operators of the bool? type, as described in §7.11.3). Otherwise, the lifted operator unwraps the operands, applies the underlying operator, and wraps the result. · For the equality operators ==!= a lifted form of an operator exists if the operand types are both non-nullable value types and if the result type is bool. The lifted form is constructed by adding a single? modifier to each operand type. The lifted operator considers two null values equal, and a null value unequal to any non-null value. If both operands are non-null, the lifted operator unwraps the operands and applies the underlying operator to produce the bool result. · For the relational operators < > <= >= a lifted form of an operator exists if the operand types are both non-nullable value types and if the result type is bool. The lifted form is constructed by adding a single? modifier to each operand type. The lifted operator produces the value false if one or both operands are null. Otherwise, the lifted operator unwraps the operands and applies the underlying operator to produce the bool result. Member lookup A member lookupis the process whereby the meaning of a name in the context of a type is determined. A member lookup can occur as part of evaluating a simple-name (§7.6.2) or a member-access (§7.6.4) in an expression. If the simple-name or member-access occurs as the primary-expression of an invocation-expression (§7.6.5.1), the member is said to be invoked. If a member is a method or event, or if it is a constant, field or property of either a delegate type (§15) or the type dynamic (§4.7), then the member is said to be invocable. Member lookup considers not only the name of a member but also the number of type parameters the member has and whether the member is accessible. For the purposes of member lookup, generic methods and nested generic types have the number of type parameters indicated in their respective declarations and all other members have zero type parameters. A member lookup of a name N with K type parameters in a type T is processed as follows: · First, a set of accessible members named N is determined: o If T is a type parameter, then the set is the union of the sets of accessible members named N in each of the types specified as a primary constraint or secondary constraint (§10.1.5) for T, along with the set of accessible members named N in object. o Otherwise, the set consists of all accessible (§3.5) members named N in T, including inherited members and the accessible members named N in object. If T is a constructed type, the set of members is obtained by substituting type arguments as described in §10.3.2. Members that include an override modifier are excluded from the set. · Next, if K is zero, all nested types whose declarations include type parameters are removed. If K is not zero, all members with a different number of type parameters are removed. Note that when K is zero, methods having type parameters are not removed, since the type inference process (§7.5.2) might be able to infer the type arguments. · Next, if the member is invoked, all non-invocable members are removed from the set. · 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: o If M is a constant, field, property, event, or enumeration member, then all members declared in a base type of S are removed from the set. o If M is a type declaration, then all non-types declared in a base type of S are removed from the set, and all type declarations with the same number of type parameters as M declared in a base type of S are removed from the set. o If M is a method, then all non-method members declared in a base type of S are removed from the set. · Next, interface members that are hidden by class members are removed from the set. This step only has an effect if T is a type parameter and T has both an effective base class other than object and a non-empty effective interface set (§10.1.5). 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 S is a class declaration other than object: o If M is a constant, field, property, event, enumeration member, or type declaration, then all members declared in an interface declaration are removed from the set. o If M is a method, then all non-method members declared in an interface declaration are removed from the set, and all methods with the same signature as M declared in an interface declaration are removed from the set. · Finally, having removed hidden members, the result of the lookup is determined: o If the set consists of a single member that is not a method, then this member is the result of the lookup. o Otherwise, if the set contains only methods, then this group of methods is the result of the lookup. o Otherwise, the lookup is ambiguous, and a binding-time error occurs. For member lookups in types other than type parameters and 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. Base types 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 an enum-type, the base types of T are the class types System.Enum, System.ValueType, and object. · If T is a struct-type, the base types of T are the class types System.ValueType and 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 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 Except for destructors and static constructors (which cannot be invoked explicitly), 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. The argument list (§7.5.1) of a function member invocation provides actual values or variable references for the parameters of the function member. Invocations of generic methods may employ type inference to determine the set of type arguments to pass to the method. This process is described in §7.5.2. Invocations of methods, indexers, operators and instance constructors employ overload resolution to determine which of a candidate set of function members to invoke. This process is described in §7.5.3. Once a particular function member has been identified at binding-time, possibly through overload resolution, the actual run-time process of invoking the function member is described in §7.5.4. The following table summarizes the processing that takes place in constructs involving the six categories of function members that can be explicitly invoked. 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.
Argument lists Every function member and delegate 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 instance constructors, methods, indexers and delegates, the arguments are specified as an argument-list, as described below. For indexers, when invoking the set accessor, the argument list additionally includes the expression specified as the right operand of the assignment operator. · 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 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 properties (§10.7), events (§10.8), and user-defined operators (§10.10) are always passed as value parameters (§10.6.1.1). The arguments of indexers (§10.9) are always passed as value parameters (§10.6.1.1) or parameter arrays (§10.6.1.4). Reference and output parameters are not supported for these categories of function members. The arguments of an instance constructor, method, indexer or delegate invocation are specified as an argument-list: argument-list: argument: argument-name: argument-value: An argument-list consists of one or more arguments, separated by commas. Each argument consists of an optional argument-name followed by an argument-value. An argument with an argument-name is referred to as a named argument, whereas an argument without an argument-name is a positional argument. It is an error for a positional argument to appear after a named argument in an argument-list. The argument-value can take one of the following forms: · An expression, indicating that the argument is passed as a value parameter (§10.6.1.1). · The keyword ref followed by a variable-reference (§5.4), indicating that the argument is passed as a reference parameter (§10.6.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.6.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. Corresponding parameters For each argument in an argument list there has to be a corresponding parameter in the function member or delegate being invoked. The parameter list used in the following is determined as follows: · For virtual methods and indexers defined in classes, the parameter list is picked from the most specific declaration or override of the function member, starting with the static type of the receiver, and searching through its base classes. · For interface methods and indexers, the parameter list is picked form the most specific definition of the member, starting with the interface type and searching through the base interfaces. If no unique parameter list is found, a parameter list with inaccessible names and no optional parameters is constructed, so that invocations cannot use named parameters or omit optional arguments. · For partial methods, the parameter list of the defining partial method declaration is used. · For all other function members and delegates there is only a single parameter list, which is the one used. The position of an argument or parameter is defined as the number of arguments or parameters preceding it in the argument list or parameter list. The corresponding parameters for function member arguments are established as follows: · Arguments in the argument-list of instance constructors, methods, indexers and delegates: o A positional argument where a fixed parameter occurs at the same position in the parameter list corresponds to that parameter. o A positional argument of a function member with a parameter array invoked in its normal form corresponds to the parameter array, which must occur at the same position in the parameter list. o A positional argument of a function member with a parameter array invoked in its expanded form, where no fixed parameter occurs at the same position in the parameter list, corresponds to an element in the parameter array. o A named argument corresponds to the parameter of the same name in the parameter list. o For indexers, when invoking the set accessor, the expression specified as the right operand of the assignment operator corresponds to the implicit value parameter of the set accessor declaration. · For properties, when invoking the get accessor there are no arguments. When invoking the set accessor, the expression specified as the right operand of the assignment operator corresponds to the implicit value parameter of the set accessor declaration. · For user-defined unary operators (including conversions), the single operand corresponds to the single parameter of the operator declaration. · For user-defined binary operators, the left operand corresponds to the first parameter, and the right operand corresponds to the second parameter of the operator declaration.
|
|||||||||||||||||||||||||||||||||||||||||||||||||||||
Последнее изменение этой страницы: 2016-08-10; просмотров: 234; Нарушение авторского права страницы; Мы поможем в написании вашей работы! infopedia.su Все материалы представленные на сайте исключительно с целью ознакомления читателями и не преследуют коммерческих целей или нарушение авторских прав. Обратная связь - 3.145.61.142 (0.011 с.) |