Consider the statements about operator overloading in C++: I) All operators can be overloaded. II) We can change the basic meaning of an operator. Which option correctly evaluates these statements?

Difficulty: Easy

Correct Answer: Both I and II are false.

Explanation:


Introduction:
Operator overloading lets user-defined types interoperate with familiar syntax, but it is constrained by C++ language rules. This question evaluates two common myths about how far operator overloading can go.


Given Data / Assumptions:

  • We are discussing C++ operator overloading rules.
  • “Basic meaning” refers to fundamental properties such as arity, precedence, and evaluation order.


Concept / Approach:
Not all operators are overloadable. For example, ::, . (member access), .*, ?:, sizeof, typeid, alignof, and a few others cannot be overloaded. Moreover, overloading does not allow changing the basic meaning: you cannot alter precedence, associativity, or the number of operands; you only provide user-defined behavior for existing syntax on user-defined types.


Step-by-Step Solution:
1) Examine I: “All operators can be overloaded.” This is false due to the explicit non-overloadable set.2) Examine II: “We can change the basic meaning of an operator.” Also false—overloading cannot change precedence/arity or the core parsing behavior.3) Therefore, the correct evaluation is that both statements are false.4) Proper use: provide intuitive semantics consistent with the operator's conventional meaning.


Verification / Alternative check:
Try to declare an overload for ?: or :: and observe a compilation error; compare with legal overloads like operator+, operator[], or operator->.


Why Other Options Are Wrong:
Only I true / Only II true / Both true: each contradicts specific, well-documented language restrictions.


Common Pitfalls:
Abusing operator overloading to create surprising behavior; even when legal, keep semantics consistent with user expectations to preserve readability.


Final Answer:
Both I and II are false.

Discussion & Comments

No comments yet. Be the first to comment!
Join Discussion