Java-Gaming.org Hi !
Featured games (83)
games approved by the League of Dukes
Games in Showcase (523)
Games in Android Showcase (127)
games submitted by our members
Games in WIP (592)
games currently in development
News: Read the Java Gaming Resources, or peek at the official Java tutorials
 
    Home     Help   Search   Login   Register   
Pages: [1] 2 3 4
  ignore  |  Print  
  The hidden cost of C++  (Read 14348 times)
0 Members and 1 Guest are viewing this topic.
Offline kaffiene
« Posted 2012-09-19 00:49:39 »

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/
Offline arnaud_couturier
« Reply #1 - Posted 2012-09-19 00:53:39 »

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.
Offline sproingie

JGO Kernel


Medals: 202



« Reply #2 - Posted 2012-09-19 01:50:19 »

Gosh I bet we'll convince everyone this time around. Roll Eyes

Games published by our own members! Check 'em out!
Legends of Yore - The Casual Retro Roguelike
Online Roquen
« Reply #3 - Posted 2012-09-19 05:59:56 »

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:

1  
2  
3  
4  
public T easeC2(T t)
{
  return t.dup().mul(6).sub(15).mul(t).add(10).mul(t).mul(t).mul(t);
}
Offline Grunnt

JGO Kernel


Medals: 94
Projects: 8
Exp: 5 years


Complex != complicated


« Reply #4 - Posted 2012-09-19 06:39:57 »

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)

This comment rings true.

Offline krasse
« Reply #5 - Posted 2012-09-19 17:23:44 »

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 Smiley

Offline Sickan

Senior Devvie


Medals: 9



« Reply #6 - Posted 2012-09-19 18:03:46 »

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:

1  
2  
3  
4  
public T easeC2(T t)
{
  return t.dup().mul(6).sub(15).mul(t).add(10).mul(t).mul(t).mul(t);
}

I'm a little bit too old to count as a 12 year old, but I understand what that does.
Online Roquen
« Reply #7 - Posted 2012-09-19 18:55:32 »

You're way more clever than me if you could understand it in less than a second glance.
Offline kaffiene
« Reply #8 - Posted 2012-09-20 09:51:22 »

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.
Offline princec

« JGO Spiffy Duke »


Medals: 422
Projects: 3
Exp: 16 years


Eh? Who? What? ... Me?


« Reply #9 - Posted 2012-09-20 10:27:58 »

I don't understand it at first glance either. Main problem being chaining method calls - horrible style.

Cas Smiley

Games published by our own members! Check 'em out!
Legends of Yore - The Casual Retro Roguelike
Offline Oskuro

JGO Knight


Medals: 40
Exp: 6 years


Coding in Style


« Reply #10 - Posted 2012-09-20 10:33:21 »

It is a known fact that every time you overload an operator, Bjarne Stroustrup gets a  dollar off of your taxes.

Offline nsigma
« Reply #11 - Posted 2012-09-20 10:38:28 »

I don't understand it at first glance either. Main problem being chaining method calls - horrible style.

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!  Grin

Praxis LIVE - open-source intermedia toolkit and live interactive visual editor
Digital Prisoners - interactive spaces and projections
Online Roquen
« Reply #12 - Posted 2012-09-20 12:45:44 »

@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:
1  
2  
3  
4  
5  
6  
7  
8  
9  
10  
11  
12  
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:
1  
2  
3  
4  
5  
6  
7  
8  
9  
10  
11  
.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:
1  
2  
3  
4  
5  
6  
7  
8  
9  
10  
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:
1  
2  
3  
4  
5  
6  
7  
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! Smiley )
Offline Don Kiddick

Junior Devvie





« Reply #13 - Posted 2012-09-20 14:09:35 »

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*
Offline Riven
« League of Dukes »

« JGO Overlord »


Medals: 832
Projects: 4
Exp: 16 years


Hand over your head.


« Reply #14 - Posted 2012-09-20 14:40:35 »

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

Hi, appreciate more people! Σ ♥ = ¾
Learn how to award medals... and work your way up the social rankings
Offline Don Kiddick

Junior Devvie





« Reply #15 - Posted 2012-09-20 15:02:32 »

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.
Offline Riven
« League of Dukes »

« JGO Overlord »


Medals: 832
Projects: 4
Exp: 16 years


Hand over your head.


« Reply #16 - Posted 2012-09-20 15:08:57 »

It makes no sense to add operator overloading to existing classes like Integer. The language would gain nothing by it.

Hi, appreciate more people! Σ ♥ = ¾
Learn how to award medals... and work your way up the social rankings
Offline Don Kiddick

Junior Devvie





« Reply #17 - Posted 2012-09-20 16:07:41 »

probably right - ignore me!
Offline Sickan

Senior Devvie


Medals: 9



« Reply #18 - Posted 2012-09-20 18:51:23 »

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.
Online Roquen
« Reply #19 - Posted 2012-09-20 19:22:41 »

The question becomes just how much longer does not have operators cost you.  By far the most expensive resource is your time.
Offline Best Username Ever

Junior Devvie





« Reply #20 - Posted 2012-09-21 00:30:13 »

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.

I mentioned it on another thread. It would be great to have a Concatable<T> interface. Let List<T> implement Concatable<List<T>>, for example. ! or [] probably would be good, too. Arithmetic operators are a little more troublesome.

1  
2  
3  
4  
5  
6  
7  
8  
9  
Complex x, y, z;
// Assign initial values
z = x + y;
z.real += 1; // Okay

z = x;
x.real += 1; // Hmm

z = x + 0 + 0 + 1 - 1 + 2 - 2 + 0 * y; // What does it do? What methods get called? How many Objects need to / should get created?


There's no confusion that string + 5 is a different type of operation than number + 5. (Given you have the variable declaration or you can infer it based on whether you see function calls or -, *, /, or % operators operating on the variable nearby.) There is also no confusion that one returns a reference to a new object and one uses by value assignment semantics. Without adding a new type of type, then retrofitting classes to support arithmetic operator overloading is less effective.
Offline kaffiene
« Reply #21 - Posted 2012-09-21 01:58:14 »

@kaffiene - can you honesty say that you truly understood the equation in less than a second? 

I understood pretty much immediately that it was an equation implemented in a sequence of operations. 

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.

In my experience working with C++, enhancing maintainability or increasing readabilty was not what operator overloading does.  Actually, that was pretty much of the point of the original article - you look at the code and think it does X where it actually does Y because in this case the meaning of the operators has all changed.

Obviously you have different intuitions about readability, that's cool. I have a lot of experience of using C++ that shows operator overloading being a maintenance nightmare.  That doesn't mean that a language couldn't do it better, I suppose.
Online Roquen
« Reply #22 - Posted 2012-09-21 05:47:40 »

If you only look at languages like C++ and Perl to decide if a given language feature is good or not...you'll quickly decide that assem is king.  Forget shit designed languages...esp if they are semi-popular.  They might be practical/pragmatic to use at some point in time, but that's it.
Offline Oskuro

JGO Knight


Medals: 40
Exp: 6 years


Coding in Style


« Reply #23 - Posted 2012-09-21 09:00:44 »

The question becomes just how much longer does not have operators cost you.  By far the most expensive resource is your time.

And code readability, specially in a development team, has a massive impact on time.

In my opinion, it is always a balancing act between performance and development goals (aka deadlines). And the positive side of structured readable code is that you can always optimize bottlenecks afterwards.

The again, if you go crazy with overloading things can get worse very quickly... So... Code responsibly?

Quote from: Roquen
@Oskuro: Forget c++
  Huh

Offline princec

« JGO Spiffy Duke »


Medals: 422
Projects: 3
Exp: 16 years


Eh? Who? What? ... Me?


« Reply #24 - Posted 2012-09-21 10:16:14 »

C++ is a dead end in the evolution of programming.

Cas Smiley

Offline Oskuro

JGO Knight


Medals: 40
Exp: 6 years


Coding in Style


« Reply #25 - Posted 2012-09-21 10:27:31 »

So are Dinosaurs, and they are still cool.

Offline delt0r

JGO Knight


Medals: 29
Exp: 18 years


Computers can do that?


« Reply #26 - Posted 2012-09-21 10:43:02 »

My problem with operator overloading is operator behavior. There are 2 main aspects to that. Mathematical behavior and well "instance" behavior.

Mathematical is perhaps the biggest. If i have a field with + and * that is also commutative then well we are fine. However this is a pretty small set of types where this makes sense. Even matrices don't fit that, and so you are forced to add more meaning onto overloaded operators than the originals have. (ie can't reorder the same way)

The next is also problematic. a+b means we need to copy  a then add b to a. Otherwise everything gets screwed for larger statements. say (a+b)*b+a*c for example. This is what happens in C++ IIRC, and can end up really slow with the large amounts of bit wise copies that the compiler can't eliminate. In java the copy would need to be well defined (deep enough) to not interfere with operator overloading.

Having written things for GF(2^m) and Z_p in java, where we do fit the math behaviors of +*. Operator overloading would have been useless for creating anything that had decent performance.

I have no special talents. I am only passionately curious.--Albert Einstein
Online Roquen
« Reply #27 - Posted 2012-09-21 19:17:30 »

Devil's advocate mode:  We can agree that floats are not R and 2's comp integers are not Z.  And that many properties/identities of R and Z do not hold for their computer equivalent.  There is no special operators to indicate, for instance, that add/sub/mul in floats are not associative nor integers wrapping/modulo properties.  I have no problem with that.  Likewise for non-commutative products...don't have a problem with it being represented by the same token as one that commutes over some other type.  All of this boils down to if you don't understand the type, then you really can't understand the operations anyway.

WRT: compilers and transforms...I'm too lazy to comment ATM.  Esp since we all know this is just blah, blah, blah.
Offline delt0r

JGO Knight


Medals: 29
Exp: 18 years


Computers can do that?


« Reply #28 - Posted 2012-09-21 22:56:37 »

Things in IEEE whatever are commutative. a*b=b*a and a+b=b+a. Round of error etc is required to be exactly the same. Z_2^m  is also exact. so no idea what you are talking about.

I have no special talents. I am only passionately curious.--Albert Einstein
Offline theagentd

« JGO Bitwise Duke »


Medals: 361
Projects: 2
Exp: 8 years



« Reply #29 - Posted 2012-09-22 01:06:15 »

I like that +, -, * and / are available in GLSL, but that's only because some GPUs are vector processors so they're actually faster. Matrix-vertex multiplications are also extremely optimized...

Myomyomyo.
Pages: [1] 2 3 4
  ignore  |  Print  
 
 
You cannot reply to this message, because it is very, very old.

 

Add your game by posting it in the WIP section,
or publish it in Showcase.

The first screenshot will be displayed as a thumbnail.

SHC (24 views)
2014-11-25 12:00:59

SHC (23 views)
2014-11-25 11:53:45

Norakomi (22 views)
2014-11-25 11:26:43

Gibbo3771 (22 views)
2014-11-24 19:59:16

trollwarrior1 (36 views)
2014-11-22 12:13:56

xFryIx (74 views)
2014-11-13 12:34:49

digdugdiggy (52 views)
2014-11-12 21:11:50

digdugdiggy (46 views)
2014-11-12 21:10:15

digdugdiggy (41 views)
2014-11-12 21:09:33

kovacsa (68 views)
2014-11-07 19:57:14
Understanding relations between setOrigin, setScale and setPosition in libGdx
by mbabuskov
2014-10-09 22:35:00

Definite guide to supporting multiple device resolutions on Android (2014)
by mbabuskov
2014-10-02 22:36:02

List of Learning Resources
by Longor1996
2014-08-16 10:40:00

List of Learning Resources
by SilverTiger
2014-08-05 19:33:27

Resources for WIP games
by CogWheelz
2014-08-01 16:20:17

Resources for WIP games
by CogWheelz
2014-08-01 16:19:50

List of Learning Resources
by SilverTiger
2014-07-31 16:29:50

List of Learning Resources
by SilverTiger
2014-07-31 16:26:06
java-gaming.org is not responsible for the content posted by its members, including references to external websites, and other references that may or may not have a relation with our primarily gaming and game production oriented community. inquiries and complaints can be sent via email to the info‑account of the company managing the website of java‑gaming.org
Powered by MySQL Powered by PHP Powered by SMF 1.1.18 | SMF © 2013, Simple Machines | Managed by Enhanced Four Valid XHTML 1.0! Valid CSS!