…but if you assume that a method is ALWAYS being called for operators in C++, you will still be wrong a large portion of the time and you still don’t know what the truth is until you’ve read the code ( (a) check elements are objects and if so, (b) see if they overload operators)
You’re making a common mistake. You’re confusing the technical issue with the implications it may have in a certain context…
The technical issue is neutral and can be discussed in isolation. For example the bounds checking of arrays in Java makes some code say 10% slower than the equivalent in C++ without such checking. A totally different questions is what consequenses this has in a certain situation and if it matters to you?
I don’t quite follow you. You seem to suggest that C++ has issues too? Well of course! C++ is vastly more complex than Java and that’s one of the main advantages of Java in my view. Its simplicity.
But that doesn’t change the issues with Java I’ve mentioned. C++ allows you to keep up abstractions better in time challanged code. C++ allows you to switch off bounds checking of arrays. There are more of these and there’s no use in predending they don’t exist. If they matter to you is one thing but you cannot wish away everybody’s right to decide whether they matter to them or not. That’s what I call weak argumentation. You confuse your wishes with arguments.
You started out by claiming you know both languages and are a very competent programmer of both but I understand now that you’ve been exaggerating quite a lot.
Java has a split type system with primitives on one hand and classes on the other. C++ has the same but goes to great lengths trying to bridge the gap sporting both value semantics for objects and operator overloading. Java has another strategy introducing an increasing number of “special support” for selected classes. I could mention the + operator of String and autoboxing of the wrapper classes. I don’t think the Java way necessarily leads to a “better knowledge of what’s happening”.
Well designed so called concrete classes in C++ are as easy to use as primitives in Java and that’s the purpose. If you accept doing a + b on primitives in Java what’s so strange about doing a + b on say a Complex or a Point3D in C++? If you don’t know how the method/operator is defined you have to check it up. This applies equally to both Java and C++.
With your ramblings you have only demonstrated your ignorance. My point remains. In Java you’re more likely to discard a Point3D abstraction and use the individual floats in time challanged code. In C++ you wouldn’t have to if you had a well designed concrete Point3D class at your disposal, with or without operator overloading.
You obviously didn’t read the article I posted.
I can’t argue that point because I haven’t tried his software yet. But, it can’t be that bad, or he wouldn’t be in business for 7 years and making more than $2million a year.
IMHO The one mildly interesting thing left in this thread is charcterizing how many outright logical fallacies he/she/it has attempted to use in this non-argument:
Here’s a good site:
http://www.datanation.com/fallacies/index.htm\
And here’s a list of the ones I’ve seen go by:
- Ad Hominem attack (Attacking the peson not the argument, a favorite it seems.)
- Slothful Induction (the conclusion of a strong inductive argument is denied despite the
evidence to the contrary - False Dilemma
- From Ignorance
- Complex Question (and a related one, changing the subject)
- Consequences
- Prejudicial Language
- Popularity
- Appeal to Authority
- Hasty Generalization
- Unrepresentative Sample (acutallly NULL sample)
- Accident
- COnverse Accident
- Begging the Question
- Irellevent COnclusion
- Straw Man
and one not even listed, but popular by today’s demogogues in general, and UJ’s favrite
- Asserting facts not in evidence and with no proof
Feed and Annoy the Troll At Your Own Risk. Im not going to bother. Mental KILL-LISTS are a wonderful thing.
.uj, you really need to do some reading on whitepapers about current and recent VM techniques and thinking (and stuff going forward too for that matter). You’d know for example about bounds check hoisting, and you’d know also that one of the main reasons we choose Java is because it has bounds checking, which means that some fool’s library can’t give us a security leak from a buffer overrun, and that we can absolutely trust memory not to get buggered. You’d also know about RFE 4820062 and be looking to the future. You’d know about escape analysis, and concurrent collectors, and lock elision, and intrinsics, and so on. You’d probably realise that all of these things are why we aren’t worried about that last 10% because we’re going to get that 10% back in fairly short order and at the same time keep our guaranteed safe code. Etc. I know you’re concerned about the OP’s surprise that this hasn’t happened yet for mainstream devs but the fact is we’re at 90% already and that’s been good enough for 99% of titles for some time now.
Now please go and research this stuff because you’re not doing a great job of representing your point of view here in public armed with none of this knowledge.
Cas 
You completely failed to understand my post. Nothing you have said speaks against the point I made.
As for C++, I’ve been programming it since the time when the only implementations were C preprocessors. But you probably knew than since you know everything a priori and without resort to actual experience.
Another C-front veteran! cool!
jk
Well, this has been entertaining! I think, in light of .uj’s behavior, we will lock this thread. .uj, as many people have asked for in this discussion, if you can prove your claims, then do so. If not, please keep the noise down and contribute in a manner that is appropriate for readers of a Java Gaming forum or just go away.
-Chris
And the best part of Tim’s presentation?
“Will gladly sacrifice 10% of our performance for 10% higher productivity”
-Chris