Java-Gaming.org    
Featured games (91)
games approved by the League of Dukes
Games in Showcase (580)
games submitted by our members
Games in WIP (500)
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 12673 times)
0 Members and 1 Guest are viewing this topic.
Offline Ultroman

JGO Knight


Medals: 24
Projects: 1


Snappin' at snizzes since '83


« Reply #30 - Posted 2012-09-22 06:01:48 »

We just started C# at school, and I must admit that many of the tricks my teacher is telling us, I'd rather be without, but some are just to die for.

1  
public string Name{get; set;}


Cheesy

Also, I like that I can overload my list-operator, so I can control how it adds lists together. You know, so I can make it add things from another list so they're sorted, according to some interface or what not.

Also, this rocks:
1  
2  
3  
4  
5  
6  
7  
8  
9  
10  
11  
12  
13  
14  
15  
16  
17  
// Method:
public void SetNameAndAddress(string name, string address){ Name = name; Address = address; }

// Usage:
p.SetNameAndAddress(address: "Vestergade", name: "Jette");


// Method with default values:
public void method(string name = "Lise", string address = "Skolevej 2", bool female = true)
        {
            Name = name;
            Address = address;
            Female = female;
        }

// Usage:
p.method(Address: "Borderlands 42");


But I also constantly think..."man, these many smart things, are going to make things very confusing."
Delegates are cool, but I think I'd have trouble understanding what's going on while reading through someone's code plastered with them.

- Jonas
Offline princec

JGO Kernel


Medals: 282
Projects: 3
Exp: 16 years


Eh? Who? What? ... Me?


« Reply #31 - Posted 2012-09-22 10:19:09 »

Named parameters - I like.
Default parameter values - I like.

Java Y U NO HAV THESE THINGS?

Cas Smiley

Offline kaffiene
« Reply #32 - Posted 2012-09-22 12:32:33 »

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.

Well, I don't base my opinion on just C++.  I've had a look at how Scala does operator overloading, and it's better than C++, but it still has the same flaws:

(1) Can't tell at a glance what a = b + c means without knowing the types of a,b,c and reading their definitions if they're classes
(2) Operators inherit precendence from primitives even if it's no longer appropriate (e.g.: Vectors: a * b (cross product) should have the same precedence as a + b (addition) but the cross product gets higher prescendence because it inherits the precedence of multiplication
(3) You can't all the operators you want.  E.g. Vector dot product: I can't have a . b for vectors.

Issue 1 causes code to be hard to maintain, issue 2 causes the code you write to NOT behave like the actual written out maths because the precedence has to obey that of a different domain and issue 3 causes the whole implementation to be half arsed in the first place.  I don't hate the idea of operator overloading in principle, but in practice it's always compromised.  If you can't even *actually* represent the maths correctly due to problems 2 & 3, why even bother paying the cost of issue 1 to get a compromised half measure?
Games published by our own members! Check 'em out!
Legends of Yore - The Casual Retro Roguelike
Offline kaffiene
« Reply #33 - Posted 2012-09-22 12:37:17 »

Named parameters - I like.
Default parameter values - I like.

Java Y U NO HAV THESE THINGS?

Cas Smiley
Yup - I'd definitely agree with these.  I also really like Javascript's object and array literals.  And JSON.  And lambdas.

Offline pitbuller
« Reply #34 - Posted 2012-09-22 13:46:55 »

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.

Well, I don't base my opinion on just C++.  I've had a look at how Scala does operator overloading, and it's better than C++, but it still has the same flaws:

(1) Can't tell at a glance what a = b + c means without knowing the types of a,b,c and reading their definitions if they're classes
(2) Operators inherit precendence from primitives even if it's no longer appropriate (e.g.: Vectors: a * b (cross product) should have the same precedence as a + b (addition) but the cross product gets higher prescendence because it inherits the precedence of multiplication
(3) You can't all the operators you want.  E.g. Vector dot product: I can't have a . b for vectors.

Issue 1 causes code to be hard to maintain, issue 2 causes the code you write to NOT behave like the actual written out maths because the precedence has to obey that of a different domain and issue 3 causes the whole implementation to be half arsed in the first place.  I don't hate the idea of operator overloading in principle, but in practice it's always compromised.  If you can't even *actually* represent the maths correctly due to problems 2 & 3, why even bother paying the cost of issue 1 to get a compromised half measure?

I would never use * for cross product. In glsl it's component wise multipliaction for vectors so that would confuse many ppl.
Offline princec

JGO Kernel


Medals: 282
Projects: 3
Exp: 16 years


Eh? Who? What? ... Me?


« Reply #35 - Posted 2012-09-22 13:50:39 »

I would never use * for cross product. In glsl it's component wise multipliaction for vectors so that would confuse many ppl.
QED Smiley And thus the thread neatly explained itself.

Cas Smiley

Offline Roquen
« Reply #36 - Posted 2012-09-23 00:27:01 »

@delt0r: my non-commutative comments only about non-primitive types.  Float ops are worse in that they are non-associative and not (normally) special cased, so I don't find any big deal about using the common product token for non-commutative products.

@kaffiene: To me it seems like most people seem to base their opinion on C++ operators and a very high percentage without any real first hand experience.  I've no knowledge of scala so I cannot really comment on that implementation.  I look more to mathematical DSLs than any general purpose language for reasonable operator overloading.

Quote
(1) Can't tell at a glance what a = b + c means without knowing the types of a,b,c and reading their definitions if they're classes
Not having operators doesn't change this fact.  With or without the situation is identical.

Quote
(2) Operators inherit precedence from primitives even if it's no longer appropriate (e.g.: Vectors: a * b (cross product) should have the same precedence as a + b (addition) but the cross product gets higher prescendence because it inherits the precedence of multiplication.
I've always seen inner and outer products having higher president than add/sub.  I cannot see any logical argument to give them the same.  But ultimately that's a different story because the outer product of vector analysis isn't a product so why overload the product operator in the first place?  And besides some language do indeed allow user defined prescience rules...but that's a different can of worms and something that the vast majority of people would totally hate.  Personally I'm not in favor of.

Quote
(3) You can't all the operators you want.  E.g. Vector dot product: I can't have a . b for vectors.
No argument...more operators is all good.  If fact many algebras need many operators for operator overloading to be of any real usage.  Example Clifford algebra pretty much needs product, geometric inner and outer products, Euclidean inner and outer products and multiple conjugates to be generally useful.  But really this is a different issue.

Quote
I would never use * for cross product.
Nor should you as it's not a product.  It's an outer product, specifically: (ab-ba)/2...as such overloading product is an illogical choice.  Only being about to choice from basic operators, then the only logical choice is "^" as the wedge product is a semi-standard notation for outer products.  (SEE: later)

Quote
QED Smiley And thus the thread neatly explained itself.
Exactingly..we agree from different perspectives.  You can't prevent programmers from writing bad code, so don't even attempt to do so.

WRT: vector analysis.  I don't care about operator overloading for this algebra.  Why?  Vector analysis is like C++.  It's totally awful, which is not to be confused with useless.  It's in fact very useful, but it's a horrible algebra.  It has virtually no operators and operator chains tend to be very short...so explicit method calls instead of operators is no big deal.
Offline ra4king

JGO Kernel


Medals: 322
Projects: 2
Exp: 4 years


I'm the King!


« Reply #37 - Posted 2012-09-23 00:52:56 »

I don't understand why this kind of thread is going on AGAIN.....but I'll just repost sproingie's brilliant post:

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

Offline Best Username Ever

Junior Member





« Reply #38 - Posted 2012-09-23 06:26:25 »

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.

I suspect this was the only post in this topic made after having read "The hidden cost of C++" and made in reaction to that topic. The intent behind the thread presents an entirely different point of view than what was mentioned in the other thread, but it instantly got derailed into a "I want feature X from other language Y" thread.


There's a huge problem that is yet to be addressed here. In C++, every variable is its own object. a = b; (always) creates a copy of b and (always) overwrites and destroys the original value of a. This is why people advise each other not to sort an STL vector of strings. Quicksorting the list of Strings makes O(n log n) assignments, meaning it makes O(n log n) assignments, meaning it has to allocate new memory for a string O(n log n) times and copy the array of characters O(n log n) times. In order to not suffer poor performance due to slow heap memory allocations (ironic), some people advise each other to use a selection sort on string vectors even though it is otherwise less efficient because it makes only O(n) assignments. (Now, I don't know how much of a performance hit it causes now or if professional C++ programmers know better, but... you should note how foreign C++ is to other languages. Especially Java.)

Using this approach for objects has a lot of disadvantages (readability, maintainability, coding time, and lost opportunity for certain compiler optimizations), but it works well for user created numerical types that are a fixed size and don't involve pointers. It means that the compiler can allocate space for a variable on the stack or even in registers for custom number types. It can create the bare minimum space required and reuse space to hold intermediate values while evaluating an expression. It's still problematic, but because every variable is its own object you avoid having to make design choices as you would to implement operator overloading in Java.

In Java variables and objects are separate notions. Since Objects are currently the only custom type you can create in Java, you have to retrofit operator overloading to work with capital O Objects. How do you force immutability? Where do you allocate space? Does = make a copy as expected of primitives or does it alias two variables to the same Object as expected of class references? Would you need to create a new garbage collector to accommodate extra objects created by using operator overloading? What do you do if a reference gets leaked to another class in the middle of evaluating an expression? Do you need to create a new instance for every intermediate value? You see, operator overloading in Java would not only have the same hidden costs as C++, but if you did not change the language to create a new type of custom type then it has even more hidden costs.
Offline Oskuro

JGO Coder


Medals: 32
Exp: 6 years


Coding in Style


« Reply #39 - Posted 2012-09-23 11:46:20 »

I don't understand why this kind of thread is going on AGAIN...
C'mon, no minds will be changed, true, but the discussion is very interesting and informative.

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

JGO Kernel


Medals: 282
Projects: 3
Exp: 16 years


Eh? Who? What? ... Me?


« Reply #40 - Posted 2012-09-23 13:21:50 »

This is sort of like the "Roving Motorcycle Threads" that used to plague Cix Smiley

Cas Smiley

Offline Roquen
« Reply #41 - Posted 2012-09-23 15:09:19 »

This reminds me of the assembly programmers going on and on about how a compiler could never beat hand-written code.   What they didn't understand is that their correctness on the small scale is what made them horrible wrong on a real-world scale.

BTW: Most of the stuff about operator overloading must do this and that under the hood is compete bunk.  Like I keep saying:  Forget everything you think C++ has taught you.
Offline Oskuro

JGO Coder


Medals: 32
Exp: 6 years


Coding in Style


« Reply #42 - Posted 2012-09-24 01:30:05 »

 
Like I keep saying:  Forget everything you think C++ has taught you.

I keep saying something like: A programming language is a tool, not a philosophy or a religion, don't be afraid to take a hammer to a screw if you need to.  Tongue


Wait.... Roving motorcycle threads?  Huh

Offline kaffiene
« Reply #43 - Posted 2012-09-24 02:36:13 »


I would never use * for cross product. In glsl it's component wise multipliaction for vectors so that would confuse many ppl.

The multiplication operator is the standard mathematical operator for Vectors. 

As Cas says, the fact that this is confusing because it's used in a different way in GLSL only underlines the fact that programming languages don't actually allow you to overload operators correctly.

Offline kaffiene
« Reply #44 - Posted 2012-09-24 03:31:27 »

@kaffiene: To me it seems like most people seem to base their opinion on C++ operators and a very high percentage without any real first hand experience.  I've no knowledge of scala so I cannot really comment on that implementation.  I look more to mathematical DSLs than any general purpose language for reasonable operator overloading.

I was programming C++ before an official spec was released.  When I started with it, it was a bunch of pre-processors for a C compiler (SAS-C, in my case).  I do have a reasonable amount of experience with the C++ case, but most of my issues with operator overloading are to do with the fact that you can't actually properly represent a mathematical domain properly in code anyway (due to issues about what operators are available and their existing meanings and precedence in code)


Quote
(1) Can't tell at a glance what a = b + c means without knowing the types of a,b,c and reading their definitions if they're classes
Not having operators doesn't change this fact.  With or without the situation is identical.

No, it isn't.

Without overloading "a = b + c" is definitely an operation that does not involve classes and the definitions of a, b and c do not need to be read to understand the statement.

If you see "a.set(b.plus(c))" you know instantly that a,b and c are classes and you *will* have to read the code


Quote
(2) Operators inherit precedence from primitives even if it's no longer appropriate (e.g.: Vectors: a * b (cross product) should have the same precedence as a + b (addition) but the cross product gets higher prescendence because it inherits the precedence of multiplication.
I've always seen inner and outer products having higher president than add/sub.  I cannot see any logical argument to give them the same.  But ultimately that's a different story because the outer product of vector analysis isn't a product so why overload the product operator in the first place?  And besides some language do indeed allow user defined prescience rules...but that's a different can of worms and something that the vast majority of people would totally hate.  Personally I'm not in favor of.

If you check:
http://en.wikipedia.org/wiki/Vector_calculus#Vector_operations

You will see that Vector cross product being defined as "multiplication of two vector fields, yielding a vector field"

"I've always seen inner and outer products having higher president than add/sub.  I cannot see any logical argument to give them the same."

Show me a reference where vector cross product gets higher precedence.  Wikipedia Vector calculus page doesn't mention that.  Neither does Wolfram, nor any other reference I've ever read.


Quote
(3) You can't all the operators you want.  E.g. Vector dot product: I can't have a . b for vectors.
No argument...more operators is all good.  If fact many algebras need many operators for operator overloading to be of any real usage.  Example Clifford algebra pretty much needs product, geometric inner and outer products, Euclidean inner and outer products and multiple conjugates to be generally useful.  But really this is a different issue.

It's important because the main argument for Operator Overloading is that you should be able to represent the mathematics properly, but in practice you actually can't.  If you can't do it properly the whole *reason for* operator overloading is undermined.

Quote
I would never use * for cross product.
Nor should you as it's not a product.  It's an outer product, specifically: (ab-ba)/2...as such overloading product is an illogical choice.  Only being about to choice from basic operators, then the only logical choice is "^" as the wedge product is a semi-standard notation for outer products.  (SEE: later)

The multiplication operator is the STANDARD operator used for cross product.  Check that Wikipedia reference, or ANY Wolfram page on Vector maths.

Offline kaffiene
« Reply #45 - Posted 2012-09-24 03:33:09 »

I don't understand why this kind of thread is going on AGAIN.....but I'll just repost sproingie's brilliant post:

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

You know, no-one is actually forcing you to read the thread  Smiley
Offline ra4king

JGO Kernel


Medals: 322
Projects: 2
Exp: 4 years


I'm the King!


« Reply #46 - Posted 2012-09-24 03:37:08 »

I don't understand why this kind of thread is going on AGAIN.....but I'll just repost sproingie's brilliant post:

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

You know, no-one is actually forcing you to read the thread  Smiley
False. My OCD is forcing me to Sad

Offline kaffiene
« Reply #47 - Posted 2012-09-24 03:49:36 »

I don't understand why this kind of thread is going on AGAIN.....but I'll just repost sproingie's brilliant post:

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

You know, no-one is actually forcing you to read the thread  Smiley
False. My OCD is forcing me to Sad

Haha.  Wink
Offline princec

JGO Kernel


Medals: 282
Projects: 3
Exp: 16 years


Eh? Who? What? ... Me?


« Reply #48 - Posted 2012-09-24 11:47:03 »

We are compelled to listen. This is the bar Smiley Another round of virtual bitter plz.

Cas Smiley

Offline Ultroman

JGO Knight


Medals: 24
Projects: 1


Snappin' at snizzes since '83


« Reply #49 - Posted 2012-09-24 16:48:50 »

And lambdas.
"...and I jizzed in my pants, jizzed in my pants, jizzed in my pants."

- Jonas
Offline Roquen
« Reply #50 - Posted 2012-09-25 17:52:51 »

Quote
Without overloading "a = b + c" is definitely an operation that does not involve classes and the definitions of a, b and c do not need to be read to understand the statement.

If you see "a.set(b.plus(c))" you know instantly that a,b and c are classes and you *will* have to read the code
As I've stated before, you can't really know anything about an operator or method sequence without knowing what the types in question are.  I find this to be a non argument.  Thankfully one that is moot because the solution is the supposed problem is trivial for folks that use an IDE.  Hold yourselves kids.  Operators that are overloaded are rendered differently than built-in operators.  Go Go language AND source aware IDEs.

Quote
Show me a reference where vector cross product gets higher precedence.

Mathematica
 in: FullForm[a + b × c]
 out: Plus[a, Cross[b, c]]

Quote
You will see that Vector cross product being defined as "multiplication of two vector fields, yielding a vector field"
Note that vector is an overloaded term.  Vector fields != Gibbs vectors (3D vectors) != 2D vectors != vectors in linear algebra, etc.  I bring this up because the "cross product" is really only defined in 3 dimensions.  In all other dimensions it is some logical extension..one that matches in the 3D case and is logical in some other way(s).  Basically I'm saying let's forget vector fields.  Look here instead: http://en.wikipedia.org/wiki/Cross_product or here: http://mathworld.wolfram.com/CrossProduct.html.

Quote
The multiplication operator is the STANDARD operator used for cross product.  Check that Wikipedia reference, or ANY Wolfram page on Vector maths.
No it isn't.  The cross product is.  If it were we write them as: AB instead of A×B.  (SEE: above links)

There's a huge gap between what, say Mathematica provides in terms of operators vs. C++.  Somewhere in the middle is a sweet point appropriate for general purpose languages.

Offline princec

JGO Kernel


Medals: 282
Projects: 3
Exp: 16 years


Eh? Who? What? ... Me?


« Reply #51 - Posted 2012-09-25 22:16:01 »

I always rooted for having ascii method operators but no-one likes it for some reason. Despite the fact it doesn't break readability and is obvious what is going on.

a = a dot b;
e = c cross d;

etc.

Cas Smiley

Offline matheus23

JGO Wizard


Medals: 97
Projects: 3


You think about my Avatar right now!


« Reply #52 - Posted 2012-09-25 22:42:35 »

I always rooted for having ascii method operators but no-one likes it for some reason. Despite the fact it doesn't break readability and is obvious what is going on.

a = a dot b;
e = c cross d;

etc.

Cas Smiley
This is what Scala has... But scala also has the exact same method for operators (so you can name methods "+", i. e.).

See my:
    My development Blog:     | Or look at my RPG | Or simply my coding
http://matheusdev.tumblr.comRuins of Revenge  |      On Github
Offline kaffiene
« Reply #53 - Posted 2012-09-26 01:34:52 »

@Roquen: Mathematica is a programming environment for mathematics.  The choices made there are just programming language choices and don't constitute a mathematical reference.

The reference you referred to (Wikipedia) uses this notation for cross product: a X b, which is precisely what I referring to - that is that standard notation for the multiplication operation.

@Cas: there's really very little difference from "a = a dot b" and "a =  a.dot(b)", so... would a change like that be worth it?

Offline Best Username Ever

Junior Member





« Reply #54 - Posted 2012-09-26 03:49:37 »

This reminds me of the assembly programmers going on and on about how a compiler could never beat hand-written code.   What they didn't understand is that their correctness on the small scale is what made them horrible wrong on a real-world scale.

BTW: Most of the stuff about operator overloading must do this and that under the hood is compete bunk.  Like I keep saying:  Forget everything you think C++ has taught you.

I agree with the first point. Your second comment makes no sense. Technically, a programming language does not have to do much under the hood at all. We could implement classes with hash tables with string based keys for both variables and functions. Garbage collector? Meh, a semi space copying garbage collector is good enough. Fast array accesses and fast for loops? Who needs them when you have regular expressions? bytes, shorts, chars, ints, longs? Make everything that isn't an array or a string a double. While we're at it, make strings and arrays interchangeable.

C++ is as terrible model for Java, but that's not the point. C++ has some features (of questionable value) that cannot be sensibly implemented in Java. You can't take a feature from C++ and drop it into Java, just as you can't take a feature from Java and drop it into Javascript, just as you can't take a feature from Javascript and drop it into C++.

Integers are not a replacement for ints. No other class based implementation could be a replacement either. Adding syntax sugar for arithmetic operators would not change that fact at all, just hide symptoms of problems. If there was a new user defined type used specifically as operands to arithmetic operations, then Java could have the syntax sugar everyone craves and at the same time have a practical implementation under the hood. Maybe add a Java flavored version of C structs and at the same time use those for your custom math related data types. But as is, no amount of hand waving and assuring people that the problem is simple to solve can simplify or solve the problems.

If you know a way a JVM could use classes and Objects in place of primitives without adding several bytes of overhead before per instance, preserve immutability of numerical types, avoid excessive garbage generation in frequently accessed blocks of code, and preserves normal object behavior for existing classes, new classes, Generics, and the == operator, then don't keep it a secret.
Offline gimbal

JGO Coder


Medals: 25



« Reply #55 - Posted 2012-09-26 11:13:15 »

@Best Username Ever: thank you for a good read! I don't agree with you though, it is NOT the best username ever Wink
Offline Orangy Tang

JGO Kernel


Medals: 51
Projects: 11


Monkey for a head


« Reply #56 - Posted 2012-09-26 11:43:32 »

You can't take a feature from C++ and drop it into Java, just as you can't take a feature from Java and drop it into Javascript, just as you can't take a feature from Javascript and drop it into C++.

People keep trying though.  persecutioncomplex

[ TriangularPixels.com - Play Growth Spurt, Rescue Squad and Snowman Village ] [ Rebirth - game resource library ]
Offline princec

JGO Kernel


Medals: 282
Projects: 3
Exp: 16 years


Eh? Who? What? ... Me?


« Reply #57 - Posted 2012-09-26 12:06:36 »

I think the C-like lexical appearance is what fools people. I do rather like the conciseness though.

Cas Smiley

Offline Roquen
« Reply #58 - Posted 2012-09-26 15:03:05 »

Quote
... uses this notation for cross product: a X b, which is precisely what I referring to - that is that standard notation for the multiplication operation.
In arithmetic sure. 10×5.  Or sometime when you're abstractly talking about some (potentially unspecified) field, but then again it's almost as common to use a 'dot' as well.  But we're talking about a specific algebra:

Standard notation for vectors:  let small letters be scalars and capitals be vectors:

product of a vector with a scalar: sV  (no cross symbol)
cross product:  A×B
dot product: A.B
product:  AB -  Doesn't exist..it isn't representable in terms of vector

Don't like that?  How about from MathWorld: "Vector multiplication is not uniquely defined, but a number of different types of products, such as the dot product, cross product, and tensor direct product can be defined for pairs of vectors."

Quote
Mathematica is a programming environment for mathematics.  The choices made there are just programming language choices and don't constitute a mathematical reference.
So, let me get this straight:
  • Vectors for some reason don't obey the standard convention of placing product-like structures ahead of addition-like structures.
  • Mathematica's InputForm, the sole intent of which is to write equations in the exact same manner as one would on paper, is incorrect for a simple equation using Cross, when that operator has no builtin meaning other than the vector cross product.
  • All references of the vector identities contain incorrect statements as they include: A+B = B+A, which means that: A×B+C = C+A×B and using you're version of ordering means: (A×B)+C = (C+A)×B which is incorrect.
  • Or another:  (A+B)×C = A×C+B×C != (A×C+B)×C.  And notice in the first that the paren shouldn't be needed if you're correct, so why are they there?

I wave my hands and invoke Occam's razor (lex parsimoniae!)

@Best Username Ever: Errr..your post is all over the place.

Quote
Technically, a programming language does not have to do much under the hood at all.
I depends on what kind of language you're talking about.  The higher level you get...more and more is happening "under the hood".  That's the nature of the game.

Quote
Garbage collector? Meh, a semi space copying garbage collector is good enough.
Wash your mouth out with soap.  Sure, as long as performance and spending twice the required memory is of no concern.

Quote
We could implement classes with hash tables with string based keys for both variables and functions. ... Fast array accesses and fast for loops? Who needs them when you have regular expressions? bytes, shorts, chars, ints, longs? Make everything that isn't an array or a string a double. While we're at it, make strings and arrays interchangeable.
Umm..yeah.  Well languages like this exist.  But what does this have to do with operators?

Quote
C++ is as terrible model for Java, but that's not the point. C++ has some features (of questionable value) that cannot be sensibly implemented in Java. You can't take a feature from C++ and drop it into Java, just as you can't take a feature from Java and drop it into Javascript, just as you can't take a feature from Javascript and drop it into C++.
Like I keep saying: forget C++.  C++ is a terrible period and has no bearing on this conversion as far as I'm concerned.  I'm not advocating adding anything C++ like thing.  And since I haven't mentioned in this thread.  Personally I could care less if Java ever gets operator overloading, but I'm able to look beyond my own bellybutton to the needs of other programmers.  I can implement operators exactly as I would like them to work.  Likewise lambda were never high on my list.  But adding lambdas is fantastic for the language.  (And yeah, I'll use lambda, but I'm really much more interested in the JVM changes that this language addition is providing).  Not having operators make java much less attractive option to programmers in some fields either without a basic compiler background, a willingness to use an extended version (which even I would hate) or can't be bother with the additional hassle of either of the previous.  That's a heck of a lot of people.

Quote
If you know a way a JVM could use classes and Objects in place of primitives without adding several bytes of overhead before per instance
Structs, arrays of struct and concrete arrays.  Assuming that you're talking about over non-primitives types.  There's significant work currently going all to address auto-magic, approaching zero overhead boxing/unboxing if that's what you mean.  (As an aside, I'm really curious about what they mean by "no more primitive types" as one of the JDK10 bullet-points)

Quote
avoid excessive garbage generation in frequently accessed blocks of code
above + contracts + escapes

Quote
preserve immutability of numerical types
I not getting this point.  We're not purely functional and a type is either mutable or immutable by it's definition.

Does that cover everything or did I miss something?
Offline sproingie
« Reply #59 - Posted 2012-09-27 01:11:04 »

Funny thing about primitives: they're a compiler optimization, they need not be exposed at the language level.  Smalltalk has never really had them, and most of Java's JIT technology came from smalltalk derivatives (Self and Strongtalk).  Scala also doesn't have them, yet it also emits bytecode that uses primitives -- in fact, because of annotations like @specialized, it's able to do so in more places than Java (potentially anyway, it still does a lot of boxing.  The compiler is slow enough without trying to be even smarter than it is)

Java did not start out with JIT at all, and therefore did not launch with many ambitions to advance the state of its compiler to leave out the primitive/object distinction or even blur it in any way.

Sure you can still hand-optimize quite a lot of code with primitives ... just like you can if you wrote everything in C.
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.

xsi3rr4x (51 views)
2014-04-15 18:08:23

BurntPizza (48 views)
2014-04-15 03:46:01

UprightPath (63 views)
2014-04-14 17:39:50

UprightPath (45 views)
2014-04-14 17:35:47

Porlus (62 views)
2014-04-14 15:48:38

tom_mai78101 (86 views)
2014-04-10 04:04:31

BurntPizza (146 views)
2014-04-08 23:06:04

tom_mai78101 (243 views)
2014-04-05 13:34:39

trollwarrior1 (202 views)
2014-04-04 12:06:45

CJLetsGame (209 views)
2014-04-01 02:16:10
List of Learning Resources
by SHC
2014-04-18 03:17:39

List of Learning Resources
by Longarmx
2014-04-08 03:14:44

Good Examples
by matheus23
2014-04-05 13:51:37

Good Examples
by Grunnt
2014-04-03 15:48:46

Good Examples
by Grunnt
2014-04-03 15:48:37

Good Examples
by matheus23
2014-04-01 18:40:51

Good Examples
by matheus23
2014-04-01 18:40:34

Anonymous/Local/Inner class gotchas
by Roquen
2014-03-11 15:22:30
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!