Java 1.5

[Banana fanna fo fanna]

But you can't do syntactically beautiful things in Java!

[Skywing]

I disagree - I *hate* operator overloading.  It makes things happen that shouldn't happen which just confuses things.

std::string a ="123test" + 3;
That should make a point to the character array "test", and it's impossible to figure out what's going on without the documentation because of the two overloads (= and +).

Operator overloading can be handy as long as you know exactly what is going on.

One of the nice things about it is that you can have template functions that work (without code changes) for both primitive and user-defined types.

[iago]

Operator overloading can be handy as long as you know exactly what is going on.

If you could always know what's going on it might not be so bad, but, especially when using a class you didn't write, you might not be able to tell when you're using an overloaded operator or now.  

[Skywing]

Operator overloading can be handy as long as you know exactly what is going on.

If you could always know what's going on it might not be so bad, but, especially when using a class you didn't write, you might not be able to tell when you're using an overloaded operator or now.  

That's what documentation is for.  You can't really tell exactly what a particular function call does without documentation, either.

Besides, STL is very well documented...

[iago]

Operator overloading can be handy as long as you know exactly what is going on.

If you could always know what's going on it might not be so bad, but, especially when using a class you didn't write, you might not be able to tell when you're using an overloaded operator or now.  

That's what documentation is for.  You can't really tell exactly what a particular function call does without documentation, either.

Besides, STL is very well documented...

But if you see a function like "dosomething(a)", you'll always know that a function is being called, but if you see "a = 17" you might not be able to tell that it's calling an overloaded function.  

I just think that code clarity is lost when you overload operators..

[Banana fanna fo fanna]

When I was a Java programmer, I said that too.

[Adron]

I just think that code clarity is lost when you overload operators..

Code clarity can be gained or lost. Many things look much clearer when you can use overloaded operators. Large number classes is an excellent example of that.

bignum a, b, c;
a.assign(4);
b.assign(1);
c.assign(a.multiply(b));

vs

bignum a, b, c;
a = 4;
b = 1;
c = a * b;

Overloaded assignment operator and overloaded multiplication operator makes a lot of sense.

[Maddox]

Things get confusing when you overload the dereferencing operator though.

[K]

How often do you see that?  I think the std::iterator class and derivatives do an excellent job of overloading it sensibly.

[Adron]

I see the dereferencing operator overloaded for smart pointers, collections and similars. In most cases the meaning of the operator stays the same, but the operator can be a applied to a new data type.

If you know the data types of the variables in the expression, you'll then know that you're looking at an overloaded operator. If it wasn't an overloaded operator, it would be a compile error.

[iago]

I just think that code clarity is lost when you overload operators..

Code clarity can be gained or lost. Many things look much clearer when you can use overloaded operators. Large number classes is an excellent example of that.

bignum a, b, c;
a.assign(4);
b.assign(1);
c.assign(a.multiply(b));

vs

bignum a, b, c;
a = 4;
b = 1;
c = a * b;

Overloaded assignment operator and overloaded multiplication operator makes a lot of sense.

I don't like that -- you don't know what's going on.  I don't like the extra layer of abstraction (says the Java user).

[Adron]

I just think that code clarity is lost when you overload operators..

Code clarity can be gained or lost. Many things look much clearer when you can use overloaded operators. Large number classes is an excellent example of that.

bignum a, b, c;
a.assign(4);
b.assign(1);
c.assign(a.multiply(b));

vs

bignum a, b, c;
a = 4;
b = 1;
c = a * b;

Overloaded assignment operator and overloaded multiplication operator makes a lot of sense.

I don't like that -- you don't know what's going on.  I don't like the extra layer of abstraction (says the Java user).

You don't like that? How can you not like a statement that clearly says that c is set to a times b, vs a complex one with a whole lot of function calls?

[iago]

In Java, I would do this:

Code Select Expand

import java.util.BigInteger;
...
BigInteger a = new BigInteger(4);
BigInteger b = new BigInteger(1);
c = a.multiply(b);


I personally prefer that over your operator overloading.

[Banana fanna fo fanna]

Then you would like Scheme/Lisp:

(* 5 (+ 2 3))

[K]

In Java, I would do this:

Code Select Expand

import java.util.BigInteger;
...
BigInteger a = new BigInteger(4);
BigInteger b = new BigInteger(1);
c = a.multiply(b);


I personally prefer that over your operator overloading.

Some of us prefer the overloaded version, but the great thing is that you could do support both and simply have the operators call the named member functions, or vice versa.