Thread: Insulted for using C++?

Originally Posted by bithub

If inline assembly was the big winner for C/C++, I would have switched to a different language years ago. In the last 10 years, I think I've used inline assembly once (and I found out later that it wasn't even needed).

I've written entire (non-trivial) applications in assembly.

That's not true. Using adaptive optimization, a Java program could (in theory) perform faster than an equivalent C++ program. In practice, this doesn't happen often today, but it could become a more common occurrence in the future. The JIT compiler has been getting better and better over the years, so it's possible that through adaptive optimization (which the HotSpot JIT compiler already uses) that Java is actually faster than C++ in the future.

Ultimately the JIT compiler executes machine code, C/C++ executes machine code. C/C++ executes on average 1 instruction per language feature.

JIT must at a minimum execute at least 3

1. Load the next bytecode
2. jump to the appropriate section of the interpreter
3. execute the code that does what the bytecode stands for.

regardless of ho efficient step 3 is it can never be faster than the same functionality implemented in C/C++ since C/C++ could simply use inline assembly to perform the exact same sequence of machine code. And then Java has to perform steps 1 and 2 while C/C++ does not.

If you mean you can take 2 equally poorly implemented horribly cumbersome and completely non-optimized programs and that JIT will eventually run faster than C/C++ perhaps, but No language can guarantee good performance if you intentionally cripple it with poorly written code.

C/C++ will never lose because it can always just implement a java interpreter and achieve parity of performance.

Originally Posted by cyberfish

The compilation cost can possibly be amortized because the most commonly run code sections and functions will be compiled to machine code. The JIT compiler can also dynamically re-compile parts of the program (and re-optimize) using profile data from the run. That makes it theoretically possible to be faster than C.

No it doesn't. It only makes it theoretically eventually as fast as C. And the key words there are theoretically, eventually, and AS FAST, not faster.

Abachler, you're assuming that the C programmer in this case produces perfect machine code, which implies the following:
1) He knows his compiler so thoroughly that he can formulate C code that produces exactly the assembly he wants; alternatively, he writes large slabs of inline assembly, but then he's no longer programming in C.
2) He knows his target machine so perfectly that he can make all the right instruction selection and scheduling decisions.
These two assumptions are ridiculous to make about the general programming population, but they're not the worst, because this further implies:
3) The compiler will always remain the same. Different compilers generate different code.
4) The target machine will always remain the same. Different CPUs have different optimal schedules.
Adaptive optimization can optimize for the machine the code is running on, no matter where it runs.

So what does this say? It says that theoretically, under ideal circumstances you can get the fastest possible implementation of an algorithm in C, in which case Java cannot beat it. But if the implementation is not the fastest possible one, then an adaptive optimizer can eventually catch up and overtake the other code.

Originally Posted by CornedBee

So what does this say? It says that theoretically, under ideal circumstances you can get the fastest possible implementation of an algorithm in C, in which case Java cannot beat it. But if the implementation is not the fastest possible one, then an adaptive optimizer can eventually catch up and overtake the other code.

Sloppy implementations will only optimize so far. A highly optimized bubble sort will still be a bubble sort, the AO wont magically turn it into a threaded merge sort. If your argument that AO can beat C only if you cripple the strength of C (closeness to the hardware) in order to gain a position where AO can beat it, then yes, in which case I can simply claim that if you cannot use AO then even sloppy C can stomp the living crap out of java. SO yes, a C programmer writing in java for the first time will probably write faster code than a java programmer coding in C for the first time, and that makes C the weaker language how...?

If you code in C you need to think like a machine so that your code will be fast and efficient, like a machine. If you code in java you can think like a human and write code that is sloppy and error prone, like a human, then rely on the compiler to fix most of your mistakes.

Looking around at the members taking part in this discussion I really don't see too many that aren't experienced enough to hand optimize their code for the specific platform it is running on. So again, when performance is critical people will optimize their code, and C lets you optimize your code much more than java, leading to better absolute performance. Because C allows you to use inline assembly, which is a language feature of C/C++, it ultimately lets you achieve the fastest possible code. In absolutely no universe whatsoever can java AO come up with ANY optimized sequence of machine instructions that cannot be simply copy and pasted into C as inline assembly. Thus it is theoretically IMPOSSIBLE for java to EVER beat C in performance. The only way it can beat C in practical use is if you use crippled code to begin with, and then you aren't testing the performance of the programming language, but rather the programmer.

edit - added clarification in magenta

Originally Posted by Bubba

I disagree. C# has been certified by ECMA and Microsoft does not own nor maintain the standard. It is no different than say ActionScript which is also ECMA certified which means Adobe had to give up the rights to it and follow whatever standards the ECMA committee set forth. Because C# is ECMA certified this means that MS cannot just change things at the drop of a hat. They must conform the standard if they want ECMA's approval of it. There is no inherent danger in developing C# applications. They will work and be supported long into the future. C# is certainly here to stay.
This is where Java utterly failed. Sun was not willing to give up the rights to the language and/or standard. Perhaps that has changed now but I do not know since I do not use Java.

I should have clarified. The problem here is that conferring ownership to a Standards body didn't change much in terms of C# implementation since the patents issues are still very unclear, at best.

I very much doubt a third-party (which is not linked to Novell) open-source or commercial endeavor taking to themselves the task of creating a new C# implementation will not be met by fierce opposition from Microsoft. Furthermore, while not entirely sure of all implications (feel free to fill me in) I very much doubt that without many of those patented technologies, a third-party C# implementation will be anything more than just,

"A programing language totally unrelated to C# that just happens to have the same syntax and that cannot fulfill the standard in its entirety over patent issues".

In other words, they pretty much control the language because they are pretty much the only ones interested in implementing it. The fact Mono has been constantly under the fear of possible lawsuits which have even forced the delay of certain features to acquire either formal authorization or clarification, doesn't make anyone comfortable. I understand there were recent developments on this field, with Microsoft stating something in the lines of "we pledge to not sue anyone". But then I hear that this pledge does still not extend to the whole of the framework. So it's still confusing... and I don't see anyone motivated into creating C# implementations. Do you?

The power of a programming language like C# is not to be mocked. That much we agree. I've just recently made changes to my VS installation to finally include .Net development support and plan to follow through with my apprenticeship soon enough. But C# will remain forever a Microsoft controlled Windows programming language. And I'll happily eat my hat if I'm ever proved wrong.

But C# will remain forever a Microsoft controlled Windows programming language. And I'll happily eat my hat if I'm ever proved wrong.

Eat your hat eh? That would be fun to watch.

AFAIK ECMA controls C# but if MS is attempting to sue for Mono then that does not bode well since it indicates they still feel they have some type of 'ownership' over it. They would do well to relenquish control over it since that is the only time it will gain popularity. Perhaps they are threatening to sue since Mono might represent a threat, albeit small, to the Windows OS. Last I checked Linux only had a 0.7% OS market share (Feb. 2009) and Mac had 9%. That leaves MS with roughly 90% of the OS market share. They used to have about 95 to 96 percent share so maybe they are trying to regain some of that by squashing the little guy again.

Originally Posted by abachler

Java and C# are the easy button of programming languages. Great for writing flash ads that try to sell natural male enhancements, but not really for serious high performance computing. I don't think Java has support for CUDA is what I'm saying. i also don't think anyone is tarded enough to write an OS in C#.

Really could not have said it any better.

Originally Posted by Bubba

I disagree. C# has been certified by ECMA and Microsoft does not own nor maintain the standard. It is no different than say ActionScript which is also ECMA certified which means Adobe had to give up the rights to it and follow whatever standards the ECMA committee set forth. Because C# is ECMA certified this means that MS cannot just change things at the drop of a hat. They must conform the standard if they want ECMA's approval of it. There is no inherent danger in developing C# applications. They will work and be supported long into the future. C# is certainly here to stay.
This is where Java utterly failed. Sun was not willing to give up the rights to the language and/or standard. Perhaps that has changed now but I do not know since I do not use Java.

Java (Sun's compiler and JVM) has been released under the GPL. It is leaps and bounds more open than C# is (and ever will be most likely).

Originally Posted by Kennedy

Ya know, bubba, those kind of statistics are just plain BULL CRAP!!! The fact of the matter that there are too many variables to determine what % each has. For example, of the embedded world, Linux rules with a nice margin at 60%.

I mean, really, if we said Of the 34 year old, 225 lbs, white, lives in Alabama, male, married, drives jeep, jeep is black, just bought a new house, brown headed people use Linux on a day to day basis as our poll, the outcome would be 100%.

How many embedded systems are there versus desktops?

I think what he meant to say was the Desktop OS market share. This conveniently ignores embedded and server systems where Linux is more popular than Windows.