Hrm. So, as a developer, I usually expect that anyone who has implemented a class that I might reasonably expect to call standard library algorithms (e.g. std::sort or std::max_element) on has implemented whatever functions or operators (e.g. operator<) I will need to be able to use those algorithms. For instance, given a class Complex which represents complex numbers, I should be able to identify the largest or smallest item in a container of Complex via a call to std::max_element or std::min_element respectively -- each of which rely on std::less, which in turn relies on operator< being overloaded (which actually means "defined") for the type Complex. If operator< isn't overloaded, code which invokes anything that ultimately relies on that operator just won't compile.
As a developer, I neither need to know nor care what's going on under the hood; this is the magic of encapsulation. (As an implementor, sometimes I'm curious how other people did it.) I merely want a promise from the implementor (e.g., in the class documentation) that necessary operators are overloaded in some meaningful way. operator++ should increment its caller sanely, e.g., incrementing a Date object whose value is February 28, 2008 should produce a Date whose value is February 29, 2008. Similarly, adding n Length and m Length should give me n+m Length, but multiplying n Length and m Length should give me n*m Area.
All that said, it's absolutely possible to overload operators in unhelpful ways. I actually agree with Elliotte Rusty Harrold (http://cafe.elharo.com/blogroll/operator-overloading/)'s argument that people who don't have a basic grasp of groups, rings and fields, and who don't understand dimensional analysis ("apples plus apples is denoted in apples, but apples times apples is denoted in units of apples squared"), really have no business overloading operators. Fortunately, dimensional analysis is easy to pick up if one has forgotten it from high school physics, and the fundamentals of abstract algebra can be picked up in half an hour.
no subject
As a developer, I neither need to know nor care what's going on under the hood; this is the magic of encapsulation. (As an implementor, sometimes I'm curious how other people did it.) I merely want a promise from the implementor (e.g., in the class documentation) that necessary operators are overloaded in some meaningful way. operator++ should increment its caller sanely, e.g., incrementing a Date object whose value is February 28, 2008 should produce a Date whose value is February 29, 2008. Similarly, adding n Length and m Length should give me n+m Length, but multiplying n Length and m Length should give me n*m Area.
All that said, it's absolutely possible to overload operators in unhelpful ways. I actually agree with Elliotte Rusty Harrold (http://cafe.elharo.com/blogroll/operator-overloading/)'s argument that people who don't have a basic grasp of groups, rings and fields, and who don't understand dimensional analysis ("apples plus apples is denoted in apples, but apples times apples is denoted in units of apples squared"), really have no business overloading operators. Fortunately, dimensional analysis is easy to pick up if one has forgotten it from high school physics, and the fundamentals of abstract algebra can be picked up in half an hour.