لطفا منتظر باشید ...
Discussion
Although anyone would agree (we hope) that one should not implement subtraction in an operator+ implementation, other cases can be subtle. For example, does your Tensor class's operator* mean the scalar product or the vector product? Does operator+=( Tensor& t, unsigned u ) add u to each of t 's elements, or will it resize t ? In such ambiguous or counterintuitive cases, prefer using named functions instead of fostering cryptic code.Item 32): "When in doubt, do as the int s do." [Meyers96] Mimicking the behavior of and relationships among operators on built-in types ensures that you don't surprise anyone. If your semantics of choice are likely to raise eyebrows, maybe operator overloading is not a good idea.Programmers expect operators to come in bundles. If the expression a @ b is well formed for some operator @ you define (possibly after conversions), ask: Can the caller also write b @ a without surprises? Can the caller write a @= b ? (See Item 27.) If the operator has an inverse (e.g., + and - , or * and / ), are both supported?Named functions are less likely to have such assumed relationships, and therefore should be preferred for clearer code if there can be any doubt about semantics.
