Tag Info

Hot answers tagged

22

Abstraction 'hides' code so you don't have to be concerned about the inner workings and often so you can't change them, but the intention was not to prevent you from looking at it. We just make assumptions about operators and like Joel said, it could be anywhere. Having a programming feature requiring all overloaded operators to be established in a specific ...


9

IMHO, language features such as operator overloading give the programmer more power. And, as we all know, with great power comes great responsibility. Features that give you more power also give you more ways to shoot yourself in the foot, and, obviously, should be used judiciously. For example, it makes perfect sense to overload the + or the * operator ...


7

In Haskell "+", "-", "*", "/" etc are just (infix) functions. Should you name an infix function "plus" as in "4 plus 2"? Why not, if addition is what your function does. Should you name your "plus" function "+"? Why not. I think the issue with so called "operators" are, that they mostly resemble mathematical operations and there are not many ways to ...


6

A reference serves one purpose: to act as an alias for an existing variable: int i; int &ri = i; In this example, the addresses of i and ri are identical (&i == &ri). The two names refer to the very same location in memory. Thus one of the useful applications of references is to provide an alias for a long name that it would be wasteful to ...


5

I somewhat agree. If you write multiply(j,5), j could be of a scalar or matrix type, making multiply() more or less complex, depending on what j is. However, if you abandon the idea of overloading altogether, then the function would have to be named multiply_scalar() or multiply_matrix() which would make it obvious what's happening underneath. There's ...


5

Based on the other answers I've seen, I can only conclude that the real objection to operator overloading is the desire for immediately obvious code. This is tragic for two reasons: Carried to its logical conclusion, the principle that code should be immediately obvious would have us all still coding in COBOL. You don't learn from code that is ...


4

Despite "I'm not considering static methods, just operators", the statement immediately before it suggests you are asking for a static operator(). If this were possible, the most vexing parse would be much more vexing! Upon further inspection, it reads like you are basically in the market for a static function. The whole purpose of operator() is to make a ...


4

I see two problems with operator overloading. Overloading changes the semantics of the operator, even if that is not intended by the programmer. For example, when you overload &&, || or ,, you lose the sequence points that are implied by the built-in variants of these operators (as well as the short-circuiting behaviour of the logical operators). ...


2

One difference between overloading a * b and calling multiply(a,b) is that the latter can easily be grepped for. If the multiply function isn't overloaded for different types then you can find out exactly what the function is going to do, without having to track through the types of a and b. Linus Torvalds has an interesting argument about operator ...


2

I think that overloading math operators is not the real issue with operator overloading in C++. I think overloading operators that should not rely on the context of the expression (i.e. type) is "evil". E.g. overloading , [ ] ( ) -> ->* new delete or even the unary *. You have a certain set of expectations from those operators that should never change. ...


2

Technically, there are not much differences between variable of type int* and int& (except those syntactical details about dereferencing and member access). The main difference in practical use IMHO is that you cannot change the object a reference is refering to after initializiation (while you can change the adress a pointer points to), and a reference ...


1

The easiest way to limit the combinatorial explosion of your overloads is to introduce a small helper class that can accept all the various types and convert them to a single common type. For example class FileHelper { public: FileHelper(HANDLE& h) : handle(h) {} FileHelper(const TCHAR* fName) : handle(openFile(fName) {} FileHelper(const ...


1

A reference is another name(alias) for an existing object; it gives you the power of "pass by reference" and the convenience of using it like you would the object itself. In your example, the address of ri and i are the same and the values of each are the same. How the compiler handles this is another topic, but it really does boil down to my first ...


1

Technically speaking, references are not objects and you cannot reason about their contents. However, in reality, as pointers under the hood that's how they're often implemented. As for the function declaration/definition, they are not operators. They are syntax. int& is a type. It means "I return a reference". Returning an int& isn't any different ...


1

In comparison to spelled out methods, operators are shorter, but also they don't require parentheses. Parentheses are relatively inconvenient to type. And you must balance them. In total, any method call requires three characters of plain noise compared to an operator. This makes using operators very, very tempting. Why else would anyone want to this: cout ...


1

In addition to what has already been said here, there's one more argument against operator overloading. Indeed, if you write +, this is kind of obvious that you mean addition of something to something. But this is not always the case. C++ itself provides a great example of such a case. How is stream << 1 supposed to be read? stream shifted left by 1? ...


1

In general, I avoid using operator overloading in non-intuitive ways. That is, if I have a numeric class, overloading * is acceptable (and encouraged). However, if I have a class Employee, what would overloading * do? In other words, overload operators in intuitive ways that make it easy to read and understand. Acceptable/Encouraged: class Complex { ...


1

I suspect it has something to do with breaking expectations. I've you're used to C++, you're used to operator behavior not being dictated entirely by the language, and you won't be surprised when an operator does something odd. If you're used to languages that don't have that feature, and then see C++ code, you bring along the expectations from those other ...



Only top voted, non community-wiki answers of a minimum length are eligible