Operators in C ++

I wanted to update my blog every Monday, but I didn't expect that I was too busy in the last few weeks to sit down and write something.

This article is also written in a hurry. I hope you can point out the omissions.

As for the reference in this article, it may be partly from a certain clause in EC and should be supplemented as appropriate.

 

In C ++, defining operators for basic types is the most common task. For example, a comparison operator is provided for a custom type to allow it to be the element type of the STL Container set. In this article, we will not discuss the syntax for defining operators, but briefly introduce some issues that need to be paid attention to when defining operators.

First, we need to clarify the benefits of operators. Operators have stronger semantic features than member functions: In general, an operator is often fixed. According to this fixed meaning, type-defined operators can make the operation logic clearer. For example, the matrix44 class that represents a 4*4 matrix can support matrix multiplication by defining multiplication operators, rather than using the multiply () function. In addition, operator input is more convenient than member functionsCodeMore concise.

Many mature class libraries place great importance on the use of operators, such as boost or STL. This emphasis is also reflected in the built-in types of the Class Library and the requirements for user-defined types. The most familiar smart pointers and STL containers are very typical examples: Smart pointers rewrite common pointer operators-> and * to make their use more like a native pointer; each container usually requires the type carried by the container to provide specific operators. For example, the set container requires the Data Type carried by the container to provide comparison operators. In this way, templates and other technologies can better operate on various types under the assumption that specific operators have fixed meanings, significantly enhancing the versatility of template code.

At the same time, user-defined operators should not be used in disorder. Software developers should ensure that their original semantics is maintained for the heavy loads of operators. Otherwise, the heavy loads of operators will lose their positive meaning and will lead to misuse.

After ensuring that specific operators on a custom type have positive meanings, software developers can start to implement these operators. Before implementation, software developers should consider the following questions: should operators be member functions of the type? If not, where should the global operator be defined? Do I need to use explicit to prevent implicit calls? These are some factors that affect the User-Defined Operator Interfaces and may affect user code in the case of changes.

First, we will discuss whether operators should be member functions of the type. Once an operator is defined as a member function of the type, it can only be the left value of the operator. In this case, software developers need to consider whether it is appropriate to place the instance on the left of the operator. A proper criterion is whether the use of operators follows certain habits. The formation of these habits is often related to the combination sequence of operators and the concatenation of operators. For example, if Type X implements the operator <, software developers can use the operator x <cout as follows. The <operator is a left-bound operator, so X1 <X2 <cout calculates the <operation of X1 and X2 first, instead of the expected X2 <cout. Therefore, the <operator is often implemented as a non-member function.

If an operator requires a corresponding custom type as the right value of the operator, software developers need to define a global operator and define it as a type of friend if needed. The second parameter of the global operator must be the custom type of the operator.

Sometimes, operators need to directly change the original data to provide higher operator execution performance. This operator is often used as a type member and returns a reference. The most common example is the + = Operator of many operations.

To sum up, software developers can usually use the following rules to determine whether an operator should be implemented as a member OPERATOR:

1) The unary operator should be a member.

2) =, (), [], and-> should all be implemented as members.

3) because the internal status needs to be changed, all operators (+ =, <=, | =, etc.) with the assignment function must be member operators.

4) all other binary operators should be implemented as non-member operators.

There are several special operators :.,? :,: And * cannot be reloaded.

If you decide to define an operator as a non-member function, software developers need to consider the scope of the operator definition. Generally, the operator must be defined in the same namespace as the custom type. Only in this case can code of different namespaces correctly find the operator with the help of ADL.

Another question to be discussed is whether operators can be implicitly called? This problem is often caused by the type conversion operator. When the operator is not modified by explicit, the compiler may independently call the type conversion operator in many situations, such as when matching the parameter called by the function. By using the explicit keyword before the operator, software developers can disable the compiler from calling the type conversion operator. Note that the explicit it keyword must be used before the operator to enable the CLR extension support provided by Visual Studio.

It should be mentioned that the type conversion operator is a special case in Operator Overloading: Like constructors and destructor, it complies with the rules of no return type.

Another hidden problem related to the type conversion operator is whether it can be called implicitly during compilation. Assume that the type test defines a type conversion operator converted to testclass, And the type testclass defines an addition operator that uses int as the right value according to the member method. The expression test + 4 will cause an editing error for the test variable. If software developers implement this operator as a global operator, the compiler will complete compilation smoothly. This is because the compiler uses different mechanisms to handle these two cases: function call overloading and parameter matching. To put it simply, the compiler does not support implicit type conversion when searching member operators. When using global operators, the compiler automatically converts parameter search conversion operators.

Once the signature of the operator is determined, the software developer can implement the operator logic based on the actual functions required by the operator. In implementation, the performance of operators should be considered: If operators are called frequently, the execution performance of the operators will be an important factor to consider. Generally, software developers need to consider two major performance optimization methods: inline and nrv optimization. Inline is generally suitable for operators with simple execution logic, while nrv optimization is more suitable for Type instances that consume a large amount.

 

Reprinted please indicate the original address: http://www.cnblogs.com/loveis715/archive/2012/01/08/2316688.html

Business reprint please contact me in advance: silverfox715@sina.com