Operator overloading – da sau ba?

Nu e nimic de adorat aici

Orice se poate abuza.

Ar fi interesante niste exemple concrete (macar aproximative) de cod ce abuzeaza operator overloading, cod ce-a trecut de reviews desigur.

Pai putem vede niste exemple direct din libraria standard c++

overall... ar fi "scoli de gandire":

1. cei care vor ca limbajul sa fie cat mai permisiv, sa faca ce vor, cum vor, crezandu-se in permanenta "experti" infailibili

2. cei care vor ca limbajul sa impuna reguli clare, sa limiteze pe cat posibil mecanismele ce permit cod prost, greu de citit sau predispus catre erori

Subscriu in totalitate la 2. Ajungi sa subscrii la asta in special daca ajungi la un nivel in care raspunzi pentru codul scris de altii, pentru mentenanta proiectului pe termen lung. Cand treaba e la nivel hobby sau freelancing sau poate ceva programare izolata(cum e pe la embedded), grijile sunt mai putine.

Hai sa nu dezinformam; alea nu-s exemple "direct din libraria standard C++", ci exemple de incompetenta.

Ce nu intelegi tu e ca fara programatori competenti, n-ai mai posta aici pe forum - nici n-ai avea calculator, pentru ca n-ar fi software care sa-ti permita sa-l folosesti.

-Java---------------->Systems responsibility

Pros:

- Operator overloading can make code more concise and intuitive by enabling user-defined types to behave the same as built-in types. Overloaded operators are the idiomatic names for certain operations (e.g. ==, <, =, and <<), and adhering to those conventions can make user-defined types more readable and enable them to interoperate with libraries that expect those names.
- User-defined literals are a very concise notation for creating objects of user-defined types.

Cons:

- Providing a correct, consistent, and unsurprising set of operator overloads requires some care, and failure to do so can lead to confusion and bugs.

- Overuse of operators can lead to obfuscated code, particularly if the overloaded operator's semantics don't follow convention.

- The hazards of function overloading apply just as much to operator overloading, if not more so.

- Operator overloads can fool our intuition into thinking that expensive operations are cheap, built-in operations.

- Finding the call sites for overloaded operators may require a search tool that's aware of C++ syntax, rather than e.g. grep.

- If you get the argument type of an overloaded operator wrong, you may get a different overload rather than a compiler error. For example, foo < bar may do one thing, while &foo < &bar does something totally different.

- Certain operator overloads are inherently hazardous. Overloading unary & can cause the same code to have different meanings depending on whether the overload declaration is visible. Overloads of &&, ||, and , (comma) cannot match the evaluation-order semantics of the built-in operators.

- Operators are often defined outside the class, so there's a risk of different files introducing different definitions of the same operator. If both definitions are linked into the same binary, this results in undefined behavior, which can manifest as subtle run-time bugs.

- User-defined literals allow the creation of new syntactic forms that are unfamiliar even to experienced C++ programmers.

Decision:

Define overloaded operators only if their meaning is obvious, unsurprising, and consistent with the corresponding built-in operators. For example, use | as a bitwise- or logical-or, not as a shell-style pipe.

Define operators only on your own types. More precisely, define them in the same headers, .cc files, and namespaces as the types they operate on. That way, the operators are available wherever the type is, minimizing the risk of multiple definitions. If possible, avoid defining operators as templates, because they must satisfy this rule for any possible template arguments. If you define an operator, also define any related operators that make sense, and make sure they are defined consistently. For example, if you overload <, overload all the comparison operators, and make sure < and > never return true for the same arguments.

Prefer to define non-modifying binary operators as non-member functions. If a binary operator is defined as a class member, implicit conversions will apply to the right-hand argument, but not the left-hand one. It will confuse your users if a < b compiles but b < a doesn't.

Don't go out of your way to avoid defining operator overloads. For example, prefer to define ==, =, and <<, rather than Equals(), CopyFrom(), and PrintTo(). Conversely, don't define operator overloads just because other libraries expect them. For example, if your type doesn't have a natural ordering, but you want to store it in a std::set, use a custom comparator rather than overloading <.

Do not overload &&, ||, , (comma), or unary &. Do not overload operator"", i.e. do not introduce user-defined literals.

Type conversion operators are covered in the section on implicit conversions. The = operator is covered in the section on copy constructors. Overloading << for use with streams is covered in the section on streams. See also the rules on function overloading, which apply to operator overloading as well.

Nici un limbaj nu te poate impiedica sa comiti erori!