There was a recent thread about things people don’t like about Java. In it, operator overloading was put forward as a feature that Java needs. This article from a C++ game programmer explains why I don’t like the idea of making code look like one kind of operation when it’s really something else:
http://www.rachelslabnotes.com/2009/10/the-hidden-cost-of-c/
Every function call has a hidden cost, but operator overload hides the fact that you’re calling functions. So I don’t like it.
The readability gain is not worth it IMO, and I hate magical things happening in my back.
Gosh I bet we’ll convince everyone this time around. :
Interface calls? Iterators? etc. etc. Well written lambdas will be harder to read that horrible operators…yeah yeah, barking in the wind.
Math a 12 year should be able to understand (somewhat) at a sub-second glance:
public T easeC2(T t)
{
return t.dup().mul(6).sub(15).mul(t).add(10).mul(t).mul(t).mul(t);
}
[quote]The reason for the overhead is to simplify creating larger games. So the real question then becomes a matter of deciding whether game performance is more crucial than time to market. (Steph)
[/quote]
This comment rings true.
I though operator overloading was just unneccessary syntactic sugar until I spent some time debugging an operator sequence where it would have been easy to spot the error using operator overloading.
I don’t use it anyway though
I’m a little bit too old to count as a 12 year old, but I understand what that does.
You’re way more clever than me if you could understand it in less than a second glance.
You struggle to understand a sequence of operations using the standard method calling syntax of the programming language you use all the time? It reads left to right like all method chaining sequences in Java do - if you’ve ever read Java code, it should be obvious.
I don’t understand it at first glance either. Main problem being chaining method calls - horrible style.
Cas
It is a known fact that every time you overload an operator, Bjarne Stroustrup gets a dollar off of your taxes.
hmm … now I really like this style (when the API is designed for it). I find it cleaner and easier to understand. Guess there could be a pretty even split in opinions on here about it. Maybe time for a The hidden cost of Java thread … er, actually, screw that - we’ve had about 6 threads on here in recent memory that could have had that title! ;D
@kaffiene - can you honesty say that you truly understood the equation in less than a second? If so, both you and Sickan and way more clever than me and the vast majority of programmers on the planet. Its not about trouble…it’s about read/write/maintainability.
@Oskuro - Forget c++.
@princec - no matter how you slice it, it’s awful.
If I were to write this kind of abomination, it might be like this:
public T easeC2(T t)
{
r = t.dup(); // t
r.mul(6); // 6t
r.sub(15); // 6t-15
r.mul(t); // t(6t-15)
r.add(10); // t(6t-15)+10
r.mul(t); // t(t(6t-15)+10)
r.mul(t); // t^2(t(6t-15)+10)
r.mul(t); // t^3(t(6t-15)+10) = 10t^3 - 15t^4 + 6t^5
ret;
}
Now let’s compare it to some pseudo-assembly for a primative type:
.proc easeC2
T r;
fmov r0, r1; ; t
fadd r0, #6.0; ; 6t
fsub r0, #15.0 ; 6t-15
fmul r0, r1 ; t(6t-15)
fadd r0, #10.0 ; t(6t-15)+10
fmul r0, r1 ; t(t(6t-15)+10)
fmul r0, r1 ; t^2(t(6t-15)+10)
fmul r0, r1 ; t^3(t(6t-15)+10) = 10t^3 - 15t^4 + 6t^5
.endproc
Go! Go! High level languages. OK, rewrite using composite ops:
public T easeC2(T t)
{
T r;
r = t.dup(); // t
r.msub(6,15) // 6t-15
r.madd(t,10); // t(6t-15)+10
r.mul(t); // t(t(6t-15)+10)
r.mul(t); // t^2(t(6t-15)+10)
r.mul(t); // t^3(t(6t-15)+10) = 10t^3 - 15t^4 + 6t^5
}
Oh yeah…massive improvement. And let’s remember that this is a 3 term polynomial equation at the pre-algebra level. Mathematics gets a tad bit more involved.
I’ll pass and go for something like this any day:
public T easeC2(T t)
{
@HornerExpand
T r = 10*t^3 - 15*t^4 + 6*t^5;
return r;
}
(EDIT: Horror - I forget the return statement in the assembly! )
The maths syntax is definitely more familiar and easier to understand. Whether the java-like syntax is sufficient is dependent on how much maths you are doing I guess.
Could this not be like operator overloading for Strings in java? ie. baked into the language for numbers but not open for general (mis)use. Just a thought strokes virtual beard
Problem is that suddenly every class in every libary suddenly extends java.lang.Number :persecutioncomplex:
Like with String magic overload of +, the mathematical operators could just magically work on Double, Long, AtomicLong, Integer etc. No need to declare anything at the Number level.
Also the compiler could be clever enough to use primitives to avoid the boxing overhead and aid performance. Again magic, but there already is magic hardcoded stuff like this in the jvm.
It makes no sense to add operator overloading to existing classes like Integer. The language would gain nothing by it.
probably right - ignore me!
In response to Roquen, I don’t think that I could tell you the result of that from first glance (unless it was a very long first glance), but I could work it out without much problem.
The question becomes just how much longer does not have operators cost you. By far the most expensive resource is your time.