Categories: Top ::

Coding: Java versus C/C++
Mon, 27 Feb 2006

Trying to compare any two programming languages is akin to invoking Godwin's Law (which dictates that once a usenet poster is compared to Hitler, the conversation is immediately over, and that this ultimately will occur in any sufficiently long usenet flameware.) Still, I had an argument with a fellow one morning and thought I might pose as the C/C++ wanker for a posting.

Firstly, let me get ground rules out of the way -- use the best tool for the job; folks who stick to any single language are silly, unless they also stick to one problem domain (or are in a hurry and just want to use familiar tools - nothing wrong with reaching for your favourite screwdriver, right?) Secondly, no one begins from scratch anymore unless they want to -- one of java's strengths is that it comes with an enormous amount of code ('libraries') written by other people, so of course its good at a lot of things. Likewise, C++ folks usually use fancy toolkits too, and so the old standup "C++ uses pointers so its hard" is silly as most developers use debugged libraries for the job anyway, just as with java (or any other language.) ie: Every C++ program uses STL or Boost or QT or somesuch. Third, the C++ coders will say "java is slow", which isn't strictly true anymore since modern JIT or pre-compilers can be quite good, though even I still suggest that many modern Java GUIs are often still sluggish (due to bad coding, in turn due to lack of understanding of the internals of the GUI. Java tries to hide people away from the internals, but you still need to sometimes!), depending on the host hardware. one can go on and on, but let us just say that all successful languages have their merits and place -- perl is great for hacking away and doing scripts, PHP is excellent for rapid web development, Python gets CS folks a stiffy, etc. So really, one should not be drawn into such apple versus orange discussions, but I did permit it to occur..

But lets get it straight, the java garbage collector is not the supreme being. The argument this morning was when the lad brought up the old rote line that 'C++ makes it easy to screw memory up and leak RAM'; I replied simply that one can code badly in any language (stolen from Plauger?) to suggest that it was not C++ or java in either case but more the developer.. but when pressed I made a glib comment about how bloated most java apps tend to be. Hence the argument :) (The old classic argument between vi and emacs, unix and windows, Amiga versus ST, etc.. sure, when provoked an IT person will always select an opposite side and fight it to the bitter end, right? :)

Java is not the first language with a garbage collector, nor the last; even some C++ implementations (such as C++.net) feature one (sick as that variation may be.) It can be a very very handy thing, though it can sometimes lead people to be lazy.. but thats neither here nor there. The discussion went sour when I brought up the question -- if a C++ program is written from scratch, or badly uses a library, it could leak memory.. sure, natch, but will it leak as much memory as a java app? (A *gasp* was heard, since the other lad was 100% convinced the garbage collector would save him from any bad situation. A noobie, to be sure.) I explained further, while playing the devils advocate, that a typical java app will require loading of the JVM to operate at all (no small footprint), and that the JVM often allocates some amount of RAM up front for the sandbox (another large amount of memory consumed), and that many toolkits will abuse RAM like crazy .. preloading GUI forms and artwork, or keeping them in memory forever against the need for fast return later). So my question was -- given a C++ program leaking memory, will it leak as much as a wasteful java app?

An interesting and highly loaded question there. ie: First, it assumes a leaky C/C++ program, which is really not hard to create as the language is full of pitfalls in that regard - these newer tongues such as java and C# and python and really any scripted language generally are easier to write non-memory-leaking code in, but it is still very easy to do - something many newbies forget. Still, if a developer is using a decent toolkit this is mostly moot - few newbie C++ coders will be reduced to using or understanding "char *" strings anyway. Further, a good developer is monitoring for memory leaks. So right off, we're assuming either a bad coder or an early life-cycle application that is just hacked together, or one that leaks so little that its not a concern to the developers in question. On the java side, we're assuming some bloaty GUI (ie: note that even Swing apps, infamous for their 10-20MB of wasted RAM, can be tuned nicely to discard unused forms or the like), and waiting for the GC to clean up the newspapers in the trainstation instead of having everyone throw out their trash when done with it, and assuming a JVM with all default settings. Assuming the worst in both cases, for purposes of an argument, is not really a good way to go, but it did suit my purposes of enraging the opponent ;) So assuming 'common' errors on all sides, is a C++ program going to leak as much as a java program 'loses' (not leaks)?

Ah, what a flamewar that discussion was. Playing devils advocate is a fun game, since really your goal is merely to incense the other party since that party is a 'fanboy' and easily drawn into quartering. If only he hadn't tried to bring up an invalid discussion to begin with, he could've been spared..

The lesson is .. java is a great language for its problem domain, just as other languages are. But don't get sloppy and hope the GC will save you, since you can just as easily reference some objects you'd forgotten about and effectively leak as much memory as a C/C++ program. I think they must teach java noobies in college that the GC is the reaper...

[ Category: / technology / coding / java ] [link] [Comments]