Thread: C++ compared to Java

nope, eclipse is a java based tool to develop in java.
it's primary benefit being support for multiple different jvms.
the c++ tools in eclipse are all written in java.
and every time I take distro supplied eclipse installers and install eclipse, it fails.
[ gee, like microsoft office not installing on windows, not impressive for the application or company ]
yup, every distro I have looked at I have tested the eclipse install, they have all failed to install a working version of it.
[ yet another proof java is broken beyond usability, the "end all and be all" dev tool doesn't install.

Hmm that is odd, I have never had any problems installing Eclipse, I had a couple problems with a couple plug-ins for it, but I found out that it was my fault and not the plug-in's fault. I typically don't use distro-provided software other than the base operating system and sometimes the drivers.

Eclipse is a Java-based application infrastructure. The Eclipse Platform is a generic development environment.

The Java Development Tools are the Java IDE, just like the C Development Tools are the C/C++ IDE.

By distro-supplied Eclipse installers, do you mean Linux distros? So how is that Eclipse's fault? Eclipse's own installer works flawlessly. The program's main issue is that if it's installed to a cross-user directory, it takes an admin to install or upgrade plugins, which is the actual reason I don't use Gentoo's Eclipse ebuild (which otherwise worked flawlessly, I might add).

And Eclipse's primary benefit is not supporting many JVMs. I still don't even know what you mean by that. Being installable in different versions? Others can do that. Compiling for multiple versions? Others can do that, too. Compiling for VMs by different vendors? Actually, JVM differences manifest themselves in different runtime characteristics; other than that, all programs run the same unless they use some vendor-specific functionality (such as com.sun.* or sun.* classes).

Eclipse's primary benefit is its excellent design and thus the many great plugins available for it, including the extremely good Java editor, code refactorer, source completer, etc.

And all of this has nothing to do with Java, so stop your pointless ranting.

It can move methods through the hierarchy, classes to other packages, rename methods, variables, extract string literals into constants or resource files, all that stuff. And it can do it without introducing errors in your code, which is more than can be said about most manual refactoring.

> Is there more to refractoring?

A lot more. Ultimately refactoring is about changing your code without affecting its behavior. It's not about changing your code to fix bugs or alter its behavior.

At the simplest level it can be about changing one variable name to something more readable or understandable, and at the most complex level changing your whole hierarchy structure. You refactor all the time when writing code without a strict specification behind. However, the key point behind this abstract concept is that you only do it when you don't alter your application behavior.

EDIT: I would probably add that not altering your application behavior, but improving its performance is not what refactoring is about either.

Originally Posted by Perspective

Actually you can install plug-ins into user defined directorys, independant of the eclipse install location. You just select "Add local site" or something during the install wizard.

Yes, but my installation wanted to register them in some file that lies in the main installation directory. And as a normal user I don't have write access to that file.

Well, if I remember correctly, I got that ebuild from an experimental overlay, so that may have been it.

Originally Posted by ElastoManiac

How faster is C++ compared to Java ? I tryed asking this at offical java forum but they deleted my thread...

Why do you even care? Are you actually having trouble with Java being too slow?

Disclaimer: I've programmed in both C++ and Java for quite a few years. In fact, I code J2EE applications for a living now.

In my experience, for speed, C++ is definitely the winner here. Java is written in C++, so theoretically it can't be faster than C++. Plus, Java adds a lot of baggage like runtime array bounds-checking, instead of compile-time assert() checking, runtime generics instead of compile-time templates, etc.

BUT HOLD ON! It can be faster than other less well-written C++ apps.

Java is noticeably slow on Windows PCs during startup, and for Swing GUIs and applets.

BUT HOLD ON! On Linux, Swing seems to perform much less poorly, and by using the non-standard SWT over Swing, desktop apps seem to improve remarkably in speed and native look-and-feel.