C++ operators that can not be overloaded?

Name the C++ Operators that can't be overloaded

C++ operators that can not be overloaded?
There are only four operators that cannot be overloaded:





1) .


2) .*


3) ?:


4) ::





Technically, sizeof is also an operator -- you cannot overload it either.





You cannot create new operators, nor can you change the meaning of operations involving only inbuilt types.





Nor can you change the precedence or the arity of any operator (to create unary ^ or binary !, for example)
Reply:utcursch is correct that the operators . .* ?: and :: cannot be overloaded (and he mentioned sizeof but forgot typeid). But there are other operatiors that SHOULD not be overloaded, because their semantics will change in ways that are almost certain to cause problems. These are %26amp;%26amp; || and , (the comma operator). The Boolean %26amp;%26amp; and || operators are normally short-circuiting; that is, they guarantee (1) to evaluate their left argument before their right argument, and (2) to NOT EVALUATE the right argument if the value can be determined from the left argument. This is crucial in all sorts of constructs. For example, it's typical to write something like





char *s = /* something or other */


if ((s != 0) %26amp;%26amp; (strlen(s) %26gt; n) { ... }





In this code the call to strlen() would be illegal if the char* variable s contained a null pointer, but we can be sure that this will never happen, because the (s != 0) test comes first (i.e. is on the left side of the %26amp;%26amp; operator), and %26amp;%26amp; guarantees to check the left condition first and then NOT EVALUATE the right condition if the left condition is false. (Similarly, || guarantees not to evaluate its right-hand argument if its left-hand argument is true.)





But if either operator%26amp;%26amp; or operator|| is overloaded, the overload is called as a function, with function-calling semantics. This implies, in particular, that ALL arguments are evaluated before the flow of control enters the function body. In other words, no matter how you code your implementation of %26amp;%26amp; or ||, the short-circuiting behavior has ALREADY been violated by the time your code begins to execute.





Could you write an overload anyway, and just rely on users to know that when they are using your overloaded %26amp;%26amp; and || operators, the behavior is completely different than that of the built-ins? Sure. Will users remember this? Almost certainly not. The short-circuiting behavior is considered so fundamental that even if they mean well, users of your versions are going to forget sometimes and assume it holds when it does not.





Of course, you can overload the bitwise operators %26amp; and |, which are not short-circuiting, so if you are writing a class and feel you need logical operator syntax for your class, you can use those safely.





The situation with the comma operator is similar: it is supposed to guarantee that its arguments are evaluated in left-to-right order, but an overloaded comma operator cannot make such a guarantee, because the language standard explicitly gives an implementor permission to evaluate function arguments in any convenient order, and compiler implementors take advantage of this. So there is no way a user-defined overload of the comma operator can guarantee the behavior that is fundamental to the normal semantics of the operator. This is also going to confuse people, and it's best just not to overload that operator at all.

floral