Take the 2-minute tour ×

I just read one of Joel's articles in which he says:


i = j * 5;







Please enlighten me.

share|improve this question
show 3 more comments

15 Answers

up vote 21 down vote accepted



share|improve this answer
the 'bitwise shift' operator is only called that for historical reasons. When applied to standard types, it does a bitwise shift (in the same way that the + operator adds numbers together when applied to numeric types), however when applied to a complex type, it can do what it likes, as long as it makes sense for that type. –  gbjbaanb Apr 7 at 9:33
add comment





share|improve this answer
show 4 more comments




EDIT: made my point more clear

share|improve this answer
Erm, except for what's inherited from C, C++ (and that's what Fred was asking about) does pretty much the same thing. Now what's your take on whether this is good or bad? –  sbi Dec 10 '10 at 12:39
@sbi I love operator overloading... Actually even C has overloaded operators... You can use them for int, float, long long and whatever. So what's that all about? –  FUZxxl Oct 8 '11 at 14:04
@FUZxxl: This is all about user-defined operators overloading the built-in ones. –  sbi Oct 8 '11 at 14:12
@FUZxxl: That might well be, but those opposing overloaded operators usually do not oppose using built-in + for different built-in number types, but creating user-defined overloads. hence my comment. –  sbi Oct 8 '11 at 14:23
show 1 more comment

I somewhat agree.



share|improve this answer
Good point. However, abandoning overloading altogether does not play nice with generic programming... –  FredOverflow Dec 10 '10 at 12:20
@FredO: Of course not. But generic programming is all about using the same algorithm for very different types, so those preferring multiply_matrix() won't like generic programming either. –  sbi Dec 10 '10 at 13:04
@David: Yeah, I skipped over the fact that the names might be bad. But then we might just as well assume that operator*() might do something stupid, j is a macro evaluating to an expressions involving five function calls, and whatnot. You then can't compare the two approaches anymore then. But, yes, naming things well is hard, although well worth whatever time it takes. –  sbi Dec 10 '10 at 19:21
@David: And since naming things is hard, names should be banished from programming languages, right? It's just too easy to get them wrong! ;-) –  FredOverflow Dec 11 '10 at 8:04
show 4 more comments


This is tragic for two reasons:

share|improve this answer
add comment

I see two problems with operator overloading.

share|improve this answer
@FredOverflow The second argument can be applied to anything that is "new and hot". I am not giving it as an argument to remove operator overloading from a language, but as a reason why people argue against it. As far as I am concerned, operator overloading is useful but should be used with care. –  Bart van Ingen Schenau Dec 14 '10 at 10:50
IMHO, allowing overloads of && and || in a way which does not imply sequencing was a big mistake (IMHO, if C++ was going to allow overloading of those, it should have used a special "two-function" format, with the first function being required to return a type which was implicitly convertible to an integer; the second function could take two or three arguments, with the "extra" argument of the second function being the return type of the first. The compiler would call the first function and then, if it returned non-zero, evaluate the second operand and call the second function upon it.) –  supercat Jul 19 '12 at 15:54
Of course, that's not nearly as bizarre as allowing the comma operator to be overloaded. Incidentally, one overloading-ish thing I've not really seen, but would like to, would be a means of tight-binding member access, allowing an expression like foo.bar[3].X to be handled by foo's class, rather than requiring foo to expose a member which could support subscripting and then expose a member X. If one wanted to force evaluation via actual member access, one would write ((foo.bar)[3]).X. –  supercat Jul 19 '12 at 16:02
add comment




share|improve this answer
+1, with a caveat: C++ gives you enough rope to hang yourself. But if I want to implement a linked list in C++, I'd want the ability to use [] to access the nth element. It makes sense to use the operators for data that (mathematically speaking) they are valid for. –  Michael K Dec 10 '10 at 13:41
@Michael, you cannot live with the list.get(n) syntax? –  user1249 Dec 10 '10 at 13:44
@Thorbjørn: It's actually fine as well, perhaps a poor example. Time may be better - overloading +,- would make sense rather than time.add(anotherTime). –  Michael K Dec 10 '10 at 13:50
show 8 more comments


share|improve this answer
+1 Don't make [] the equivalent of ++. –  Michael K Dec 10 '10 at 13:38
I'm saying that the potential problem of operator overloading with math operations is small compared to those operators. Doing something clever or crazy with math operators might troublesome, but the operators I listed, which people usually don't think of as operators but rather basic language elements, should always meet the expectation defined by the language. [] should always be an array-like accessor, and -> should always mean accessing a member. It doesn't matter if it's actually an array or a different container, or if it's a smart pointer or not. –  Allon Guralnek Dec 10 '10 at 21:44
add comment



share|improve this answer
Isn't the linux kernel developed in pure C? Why discuss (operator) overloading at all in this context? –  FredOverflow Dec 10 '10 at 13:26
The concerns are the same for any project with a similar development process, regardless of language. Excessive overloading can make it difficult to understand the impact of changes if all you have to go on are a few lines from a patch file. –  Scott Wales Dec 10 '10 at 13:34
@FredOverflow: The Linux kernel is in GCC C really. It uses all sorts of extensions that give its C an almost C++ feel at some times. I'm thinking of some of the fancy type manipulations. –  Zan Lynx Dec 10 '10 at 17:39
@Scott: There is no point in discussing the "evilness" of overloading with respect to projects programmed in C, because C does not have the ability to overload functions. –  FredOverflow Dec 10 '10 at 17:47
show 4 more comments



share|improve this answer
Overloaded operators should never do "something odd". It's fine if it does something complex, of course. But only overload when it has one, obvious meaning. –  Sjoerd Apr 10 '11 at 7:18
add comment



class Complex
    double r;
    double i;

    Complex operator*(const Compex& rhs)
        Complex result;
        return result;

Not acceptable:

class Employee
    std::string name;
    std::string address;
    std::string phone_number;

    Employee operator* (const Employee& e)
        // what the hell do I do here??
share|improve this answer
add comment




share|improve this answer
add comment




share|improve this answer
or, in C#, for using += to tie an event to a delegate. I don't think that blaming language features for programmer stupidity is a constructive way forward. –  gbjbaanb Oct 8 '11 at 23:50
add comment





share|improve this answer
add comment



share|improve this answer
Lorenzo: That's surely a valid question, and IMO there is no absolute answer. Some language designers (e.g. Java) obviously don't want to depend on programmer's education. –  user281377 Dec 10 '10 at 12:33
Hm... I guess I prefer languages that trust me, then :) –  FredOverflow Dec 10 '10 at 13:00
show 2 more comments

Your Answer


