Differences between C++ and Java

[Roedy Green]

A link to an essay on the differences between C++ and Java in the Java
glossary has died, so I concocted this little essay to replace it at
http://mindprod.com/jgloss/cpp.html

In Java, the sizes of int, long etc. are rigidly defined in terms of
bits. In C++ they are platform-dependent.

In Java, the JVM behaves at if it were big endian, even if internally
it is actually little-endian. In C++, the endianness is platform
dependent.

In Java, garbage collection of unreferenced objects is automatic. In
C++, you manually manage memory.

In Java, references are constrained to point only to the beginnings of
objects. In C++, you can do arithmetic on pointers and make pointers
point anywhere in the address space.

In Java you cannot overload operators. In C++, you can.

In Java, by default methods are virtual (overrideable). In C++, by
default, methods are non-virtual.

Java object code (class files containing JVM byte codes) will run
unmodified on any platform. C++ object code must be first linked to
produce an executable containing platform-specific machine
instructions. It will run only on one platform.

Java checks all subscripts that they are in bounds and all casts for
validity. C++ does not.

Java requires a JVM to execute. C++ programs are usually freestanding.
Java does not use a preprocessor. C++ makes extensive use of a macro
preprocessor.

Anything else important to say?

 

[Pep]

A link to an essay on the differences between C++ and Java in the Java
glossary has died, so I concocted this little essay to replace it at
http://mindprod.com/jgloss/cpp.html

In Java, the sizes of int, long etc. are rigidly defined in terms of
bits. In C++ they are platform-dependent.

You could argue that in Java they are still platform dependent, in that they
are set as per the Java VM (virtual machine) which is always the same
regardless of the physical machine that it is running on.

In Java, the JVM behaves at if it were big endian, even if internally
it is actually little-endian. In C++, the endianness is platform
dependent.

Again you could argue that in Java the endianess is platform dependent,
i.e.e as per the Java VM (virtual machine).

In Java, garbage collection of unreferenced objects is automatic. In
C++, you manually manage memory.

But this does not guarantee when the garbage collection will be performed in
Java, whereas in C++ you can determine when it will happen.

In Java, references are constrained to point only to the beginnings of
objects. In C++, you can do arithmetic on pointers and make pointers
point anywhere in the address space.

In Java you cannot overload operators. In C++, you can.

In Java, by default methods are virtual (overrideable). In C++, by
default, methods are non-virtual.

Java object code (class files containing JVM byte codes) will run
unmodified on any platform. C++ object code must be first linked to
produce an executable containing platform-specific machine
instructions. It will run only on one platform.

Again, arguably Java byte code will only run on one platform, i.e the Java
VM (virtual machine).

Java checks all subscripts that they are in bounds and all casts for
validity. C++ does not.

Java requires a JVM to execute. C++ programs are usually freestanding.
Java does not use a preprocessor. C++ makes extensive use of a macro
preprocessor.

Anything else important to say?

Not looking to cause an argument, just playing with words

 

[Robert Klemme]

Anything else important to say?

Interfaces

Abstract classes are done differently

MI in C++

Generics are different

Java has built in Threading and synchronization mechanisms


If you start talking about standard library functionality then there's a
lot more.

robert

 

[Roedy Green]

You could argue that in Java they are still platform dependent, in that they
are set as per the Java VM (virtual machine) which is always the same
regardless of the physical machine that it is running on.

Dependent implies change with the thing depended on changes. The
sizes are invariant in Java. They are part of the language spec. They
apply even when there is no JVM, e.g. Jet.

 

[Roedy Green]

Again you could argue that in Java the endianess is platform dependent,
i.e.e as per the Java VM (virtual machine).

Unless there is something new in nio, I don't think you can get a
program to produce different endianness files or socket streams on
different machines with the same code. In other words, it does not
depend on the platform. That even applies to 64 bit jvms.

 

[Roedy Green]

But this does not guarantee when the garbage collection will be performed in
Java, whereas in C++ you can determine when it will happen.

There is no official GC in C++ is there? It is always an add on. In
Java you can suggest when a good time to run might be, but you cannot
force it.

 

[Roedy Green]

Again, arguably Java byte code will only run on one platform, i.e the Java
VM (virtual machine).

You are in the wrong major. Take up corporate law.

 

[Roedy Green]

You are in the wrong major. Take up corporate law.

In java terminology Platform-independent refers to the ability to run
Java byte code on many different platforms if they have a JVM
implementation.

Platform refers then not to the JVM but to the OS and hardware that
host it.

 

[Pep]

In java terminology Platform-independent refers to the ability to run
Java byte code on many different platforms if they have a JVM
implementation.

Platform refers then not to the JVM but to the OS and hardware that
host it.

Like I said, I'm only playing on words.

Please don't get me wrong, I find Java to be a really useful language and
certainly prefer the extensibility and ease of use of the language compared
to that of C++.

Pep.

 

[AndyRB]

In java terminology Platform-independent refers to the ability to run
Java byte code on many different platforms if they have a JVM
implementation.

Which is alot more accurate than you original statement:
"Java object code (class files containing JVM byte codes) will run
unmodified on any platform"

 

[Thomas Hawtin]

Unless there is something new in nio, I don't think you can get a
program to produce different endianness files or socket streams on
different machines with the same code. In other words, it does not
depend on the platform. That even applies to 64 bit jvms.

The only thing I can think of involves multi-threaded access to
non-atomic longs (or doubles) on 32-bit platforms. I think the half
written writes will give the exact opposite of the half read reads.

java.nio.ByteOrder.nativeOrder() gives the byte order of the underlying
hardware. But you wouldn't be able to tell if it was lying. And it
doesn't support PDP-endian.

Tom Hawtin

 

[Benji]

There is no official GC in C++ is there? It is always an add on. In
Java you can suggest when a good time to run might be, but you cannot
force it.

I think he's referring to delete and free. it's technically "garbage
collection" - just not automatic garbage collection. =P

 

[Oliver Wong]

message [snip]

Anything else important to say?

I did not know this, but apparently in C++, you can have a variable
which is an object (as opposed to a reference to an object). I.e., in C++,
you can have:

<C++ Code?>
Object* myObject;
</C++ Code?>

which is equivalent to

<Java Code>
Object myObject;
</Java Code>

but you can also have, in C++:

<C++ Code?>
Object myObject;
</C++ Code>

which has no equivalent in Java. That is to say, in C++, you can have a
variable which a pointer to an object, or you can have a variable which is
an object itself.

I was quite surprised when I found out about this, and I wonder what the
implications of it are when writing C++ code.

See:
http://groups.google.com/group/comp.programming/msg/033a72a206f985f9

- Oliver

 

[EdwardH]

Worms and viruses that use buffer overflows can do it only due to C and C++.

 

[Oliver Wong]

Like I said, I'm only playing on words.

Please don't get me wrong, I find Java to be a really useful language and
certainly prefer the extensibility and ease of use of the language
compared
to that of C++.

I'm in agreement with Pep here. What we essentially have here is a
programming language (Java) for which compilers output a something
(bytecode), and for which we have emulators (JVMs) for running on all the
platforms which cannot "natively" run that output, whatever that may mean.

However, this does not directly address the issue of whether java is
"Platform Independent" or not. The resolution to that issue depends on the
definition used for "Platform Independent".

I don't think that it is "useful" to say that a language is platform
independent. I use "useful" here to mean that if the label "platform
independent" is useful, then there should exist some things which are
platform independent, and some things which are not.

In theory, for any (language, platform) pair, a compiler could exists
which compiles programs written in that language and produces native code
for that platform. For example, you could have a compile which takes Intel
x86 assembly with SS3 extensions and produces a native RISC excutable
binary. Does that mean that "Intel x86 assembly with SS3 extensions" is
platform independent? Probably not. With this interpretation, ALL languages
are platform independent, so it is not a "useful" definition.

Can we say that a particular sequence of bits is platform dependent? If
we have a .EXE intended to "run" on a Win32 platform, we might try to "run"
it on a MacOSX, or Linux platform and notice that it fails to give the
desired behaviour. Does this mean that this sequence of bit is platform
dependent? Maybe. But what if, by some amazing coincidence, the same
sequence of bit could be interpreted as a valid executable file on two
different platforms, but the behaviour would vary wildly? E.g. we have two
different processors with different instruction sets, and the instruction
represented by the word "0x00000001" on processor A means "add as an integer
the value in register 1 to the value in register 2 and store it in register
0" while that same word "0x00000001" means "pop 2 values off the stack and
multiply them together, and push the result back onto the stack" for
processor B.

In the above scenario, the bitstream is a valid program on both
platforms, and yet yields completely different results. It seems then that
we should not say that a particular sequence of bits is platform dependent,
but rather a (sequence of bit, intended behaviour) pair is platform
dependent. Of course, as soon as we let "intended behaviour" slip into our
definition, we're REALLY entering murky waters.

We can take a much more pragmatic (though perhaps just as equally
"murky") approach to defining it by asking this: "Does the user have to
worry about what platform they're running on to use our program?" This
definition might seem overly Java-centric though, in the sense that it was
specifically crafted so that the answer would be "No" for Java and "Yes" for
C++.

My conclusion is that if you're target audience is "end-users", use the
pragmatic definition listed above. It probably conveys the intended meaning
using terms that are at least passingly familiar with the audience.

If the target audience are compiler-writers, system engineers, or other
people who are interested in technical details, just avoid the term
"platform independent" altogether and say what you really mean.

- Oliver

 

[Oliver Wong]

Worms and viruses that use buffer overflows can do it only due to C and
C++.

That's not nescessarily true. Any time you have a fixed size buffer, you
can have a buffer overflow attack. And, AFAIK, every implementation of Java
(the platform, not the language) uses fixed size buffers under the hood. In
the case of Java, you're essentially trusting that Sun put enough checks to
catch any time code tries to write data outside the bounds of the buffer it
was assigned to.

I believe when working with low level networking APIs in Java (e.g. the
NIO package), you still need to specify a fixed buffer size. If the class
library was implemented well, you'd get IndexOutOfBoundsExceptions whenever
you tried to write outside of it, but there's always the possibility that
there's a bug in the library that might let a buffer overflow attack go
through.

- Oliver

 

[Roedy Green]

I was quite surprised when I found out about this, and I wonder what the
implications of it are when writing C++ code.

It drives you nuts. In addition to that there are multiple ways of
specifying the same thing.

You need various addressing operators including . -> * [] &

 

[Roedy Green]

I don't think that it is "useful" to say that a language is platform
independent.

Then you misunderstand something fundamental about Java, which we have
gone over before, (trying to get you to understand the difference
between native and byte code methods).

Java goes to great lengths to be platform independent. If you write a
program in 100% pure java (none of your own platform dependent native
methods) then your code should work on ANY platform that supports the
JVM without any modifications or tweaking. This is VERY unlike C/C++.

Java does not LET you write code that depends on the platform. You
CAN'T write a program in 100% pure java to tweak the windows registry,
or get the Unix task number. That is deliberate. It is not being
mean; it is to ensure your code will run everywhere.

 

[Roedy Green]

I'm in agreement with Pep here.

Then you too should drop out of computer science and take up the art
of twisting the truth for profit, namely corporate law. Both of you
are just playing silly word games.

 

[Oliver Wong]

Then you misunderstand something fundamental about Java, which we have
gone over before, (trying to get you to understand the difference
between native and byte code methods).

Of course, from my perspective, it is you who is misunderstanding.

For the discussion on native vs byte code methods, indeed, I was in
error in that I had forgotten of the existence of the "native" keyword in
Java. I think your mistake, though, is in confusing the concept of Java, the
programming language, with Java, the platform. It's a common confusion, as
both concepts have the same name (i.e. "Java"), but they are two distinct
concepts. Sun officially acknolwedges this dinction, and you will frequenty
see in their documentation reference to "the Java language" and "the Java
platform" as two distinct concepts, for example.

Java goes to great lengths to be platform independent. If you write a
program in 100% pure java (none of your own platform dependent native
methods) then your code should work on ANY platform that supports the
JVM without any modifications or tweaking. This is VERY unlike C/C++.

The counter argument to this is that the JVM is not qualitatively
different from a traditional emulator. You could write an emulator such that
C++ programs written for Unix run on Windows (see Cygwin) and vice versa
(see Wine). Does this mean that C++ is also platform independent? Like I
said in my previous post, I don't think it's useful to say a *LANGUAGE* is
platform independent, because emulators, compilers or virtual machines could
be constructed for any language/platform pair.

Java does not LET you write code that depends on the platform. You
CAN'T write a program in 100% pure java to tweak the windows registry,
or get the Unix task number. That is deliberate. It is not being
mean; it is to ensure your code will run everywhere.

I'm not sure about the truth-value of your assertion here, as it depends
on how you define a lot of things. Would you consider a Java program in
which the keyword "native" never appears to be a 100% pure Java program? If
so, I'm relatively confident I could write a Java program without ever using
the "native" keyword which does one thing on Windows, and does something
different on Unix.

Anyway, I don't see how that truth-value has any effect on the original
claim of "I don't think that it is 'useful' to say that a language is
platform independent". Are you saying that there DOES exist an unambiguous
definition for "platform independent" which can be applied to solely
programming languages (and not to the various compilers, interpreters,
virtual machines, and other tools that work with the language) which
everyone should adopt? If so, what is that definition?

If the definition says anything about what platforms programs written in
the given language "runs" on, then I argue that this definition does involve
the compilers, interpreters and virtual machines, and not just the
programming language.

This is why I believe that a programming language in isolation should
not be said to be "platform independent" or not. Maybe I'm wrong, but I
can't think of any reasonable definition that doesn't involve the tools
mentioned above.

- Oliver