I'll bet there's material on this forum already, but I've not chimed in on this subject, so I'll risk

repetition. I've written in Java (but not since about 1.4 something), and my primary language of choice is C++. Java and C++ are similar enough that at first glance one can't really be certain which language it is. After a few seconds you can tell. First, on the subject of similarity: The underlying syntax of Java is nearly identical to C++. That is, the familiar while, for, switch, if and other statements are the same in both languages. This means that the raw information you are able to communicate to the language is very similar.

Where the languages differ: Java was originated as a OOP language. C++ was developed to "overlay" OOP techniques on top of the older and ubiquitous C. As such, in C++ one can develop, with very few restrictions, a C program using a C++ compiler. Java, in contrast, requires that all functions must be member functions, and to that extent everything operates in the context of an object. There isnt much to stop you from creating one object and stuffing it with every function you intend, which defeats the notion of OOD/OOP, but you are impelled to write OOP applications in Java, whereas in C++ its merely an invitation.

C++ does have the raw, unadorned and unprotected pointer. Unlike Java (or VB), C++ can (and often does) invoke the use of the memory location at which an object is stored (or any data from the heap). This requires diligence on the programmers part to be certain that when an object is created with new (which returns a memory location where the object is created) that when the object is no longer needed, it must be deleted. Failure in diligence on this point creates memory leaks (where allocated memory is literally LOST, never recovered, and the running C++ program grows in memory requirement to the point of bursting).

However, a little discussed point that Java fans dont mention in the defense of C++, is the fact that you dont have to use the raw, unprotected pointers if you would prefer protection. There are class libraries available, and you can build your own if you like, that provide something called a smart pointer. This non-standardized concept is the use of an object to represent a pointer. This smart pointer might have several forms, but the basic idea is to make the pointer work and feel all but exactly like the Java reference. In Java, as you recall, you can make a new object, and then forget about it. You can hand the new object over to a thread, or share the object using several references to the same object, knowing that when the last one of that community lets go of the reference, Javas runtime will eventually clean up the RAM for you. The smart pointers in C++ do the same thing from a development viewpoint. The boost library (free for download) provides these types of pointers, and I

created my own in my library years ago. Another significant point that Sun thought wasnt significant, is the cycle of construction/destruction of objects. In Java, there is no destructor, and as such you might not be familiar with this notion. In C++, a constructor works like Java. However, when the object is to fall out of scope or to be deleted, a destructor function is called to clean up. This is quite useful, and many C++ developers depend upon it to the extent that they (and I) never found Java useful. For example, a file object. In C++, if you have an object that represents a file, then creating the object on the stack might represent the opening of that file. When the file object falls out of scope, the file handle will automatically close as the result of the destructor. On critical place, for me, is in synchronization of threads. In Windows one uses the CriticalSection object for thread sync. To lock a resource, you must enter a critical section, and then you must remember to leave it when the resource is released from the lock. Wrapping that notion into an object for use on the stack means youll NEVER leave a locked critical section unlocked, even when exceptions fire. Other, more trivial but useful differences include the fact that function bodies need NOT be in the declaration of the class they are in separate files. C++ has a richer set of options for developing objects (especially templates), which Java fans are all too quick disregard.

Another point to make is compatibility. The promise of Java was write once, run anywhere. However, that hasnt become reality. Microsoft was party to making this a mess, but Sun played a part as well. The rapid deprecation of Java features meant that older Java code might impose a maximum runtime version, while newer Java code might impose a minimum version which doesnt overlap. This means multiple runtime versions are required; an installation hassle beyond the typical user understands. Performance, too, is part of compatibility, and the highest performing platform was always the MS Java runtime. This meant that applications which depended on the speed of an MS JVM might perform too slowly on other platforms to be practical. Many of these issues plague C and C++ too (and to even deeper degrees), but the point I make is that Java was never quite free of them either. It may be easier for a Java developer to switch to C++ than the reverse, because C++ developers loose so many features they depend upon, whereas Java developers find themselves saddled with conflicting implementations of certain concepts. For example, C++ uses new to allocate memory, while C used malloc and calloc for allocation (with corresponding delete or free to release the memory). Still, the Java developer looses little; things simply change (sometimes drastically).