Valhalla Legends Archive

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

Quote from: iago[yL] on May 20, 2004, 07:16 AM
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.

Quote from: Skywing on May 23, 2004, 10:32 PM
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.  

Quote from: iago[yL] on May 24, 2004, 03:12 AM

Quote from: Skywing on May 23, 2004, 10:32 PM
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...

Quote from: Skywing on May 24, 2004, 09:42 AM

Quote from: iago[yL] on May 24, 2004, 03:12 AM

Quote from: Skywing on May 23, 2004, 10:32 PM
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..

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

Quote from: iago on May 24, 2004, 11:14 AM
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.

Things get confusing when you overload the dereferencing operator though.

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

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.

Quote from: Adron on May 28, 2004, 06:38 PM

Quote from: iago on May 24, 2004, 11:14 AM
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).

Quote from: iago on May 29, 2004, 01:40 PM

Quote from: Adron on May 28, 2004, 06:38 PM

Quote from: iago on May 24, 2004, 11:14 AM
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?

In Java, I would do this:
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.

Then you would like Scheme/Lisp:

(* 5 (+ 2 3))

Quote from: iago on May 29, 2004, 02:40 PM
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.