the biggest problem of java for me is the fact that a) its jit compiled, making it slower than equivalent c++ program b) everything has to be an object (which is why i dont like ruby)
The thing about java is it's compilers can do optimizations that C++ compilers are only recently catching up to. JIT compilation doesn't mean it's always going to be slower than equivalent C++ programs. And if you're using C++ instead of C, and you're not using it for the Object Oriented aspect, you may as well be using C.
The thing about java is it's compilers can do optimizations that C++ compilers are only recently catching up to. JIT compilation doesn't mean it's always going to be slower than equivalent C++ programs.
interesting could you please expand on that?
I think he means that he doesn't want EVERYTHING being an object.
correct. in java i cant write a single program without using a class ie the one that contains main. i can however use a combination of data structures and functions in c++ without being forced to have them in a class
@DTSCode
One reason is that Java can do platform-specific optimisations at runtime because it recompiles code from an intermediate form (Java bytecode) to native code, and it knows the exact processor that the native code is running on. C++ compilers, for comparison, only know the target architecture (e.g. x86, x86-64, ARM, MIPS, etc.). The code that a C++ compiler generates has to run on any processor in that architecture, which limits the assumptions it can make and thus the performance of the code it can generate. The dynamic recompiler that most JVMs have can detect the exact processor and tailor its output to it. Of course, you can do some amount of processor-specific optimisation with C++ compilers; g++ has some processor-specific flags as well as flags to enable things like SSE which can produce extremely efficient code. The advantage of Java is that the VM can do that optimisation at runtime without the risk of generating unsupported opcodes because it can detect whether the platform will support those opcodes beforehand. Of course, that does increase the startup time, but for a CPU-bound program that runs for a long time, like a video game, the extra overhead would be nothing compared to the performance gain achieved. Of course, few or no compiler optimisations can do much with an I/O-bound process. Using asynchronous I/O with events can help if the program doesn't need the I/O to complete before it can do something else (using asynchronous I/O would be pointless if you then had to wait for it to complete before moving on to the next thing).
I think another reason might be that because bytecode is a high-level machine language, it is more flexible than native code and more simple than C++, so it can be re-ordered more. It's easier for the (re)compiler to figure out what's going on.
I'm a professional C/C++ developer who migrated to java almost three years ago. I had a lot of fun reading this thread, thanks :)
I don't want to argue, but only to add one thing which was forgotten about java - and it is a great advantage.
Java have http://maven.apache.org/ and it is really cool. Project build tool can download necessary libraries for you from central repository and you need not kick around forums and at first seek for some library to implement some functionality - and then to tune it to your project and compiler.
Maven has its problems of course, but it is anyway level above all build tools like make, ant etc - mainly due to existence of central repo which is used by all of the world. This really boosts opensource code reusing, and development of important tools, libraries and frameworks.
Besides this maven can download plugins from the same repo which could be used for automated testing, running servers, checking style, deploying to production etc. Plugins are developed in the same way as libraries, so there are a lot of advantages in such an approach.
@chrisname - right, RAII and move semantics are also very, very cool features of C++, although I wouldn't say RAII is close to GC. As long as I can't create an efficient persistent map with it, it is not.
@Cubbit The nice thing about RTSJ is you need to do those special things only in the realtime parts of the code, which is often just a tiny piece of code. All the rest runs with GC and standard Java. If you write a realtime C++ app, you have to do all those special things as well. Note that in C++ memory management is not realtime without special actions taken by the programmer (using a realtime allocator on top of realtime OS is not enough).
BTW: G1 or C4 collectors allow for writing single ms latency apps with GB sized heaps. It is for sure not enough for HFT, but just fine for games, video, simulations, etc.
can i derail for a second? i have another question about jit compillers. how does one generate byte code? is it like their own made up machine code that is then translated to actual machine code? is there formalized byte code? if so, is there a site where i can learn it?
is it like their own made up machine code that is then translated to actual machine code
That's exactly what it is. One noticeable difference is that virtual machine languages tend to be stack-based instead of register-based, because where hardware registers are part of the CPU (and thus much faster to access than variables in system memory), virtual registers are in memory, so accessing them is no faster than accessing a virtual stack, which is easier to implement and to use. In code, the difference looks like this:
Yes. Java has one (Java bytecode), the .Net framework (C#, VB.Net, etc.) has one (CIL [Common Intermediate Language], pronounced "sil") and Python has one (Python bytecode).
@Cheraphy
That's nothing, I program exclusively in bytecode for a quantum virtual machine that I invented. Here's a "hello world" sample:
1 2 3 4 5 6
.def msg "Hello, world\0" // Define variable 'msg'
create in // Create new qbit to use as input
create out // Create qbit to use as output
set in, msg // Set input qbit to point to message
entangle out, r1 // Entangle input and output qbits
call writeline // Write the message
Yes, I think I've heard of it - and heard that some big projects moved to it. I know many disadvantages of maven, but for my purposes they are not crucial (and not all are fixed by gradle, it looks). Anyway both of them are something incomparably cooler than my recollections of "make". :)
I'd been learning C++ for about 2 years before I tried java and honestly I found the differences a nightmare... I know once you're in them a lot is the same but it's too much for me XD.
Although it can be dangerous at times I prefer to manage my own memory thanks. And every program having to be an actual class seems rather pointless to me too.
If you're not bothered by any of this then just look a at the obvious pros and con's...
Why choose C++
Faster execution speeds(because it's fully compiled)
Cheaper memory handling and more control over it too
Compatible with nearly all machines (unless you use system specific code)
Direct links into OS's