Differences between C++ and Java

[AndyRB]

...

This was one of the things that amused me when I programmed in C/C++ many,
many years ago, that a "long" not necessarily needed to be "longer" than an
"int"... ;-)

I'm not sure that you by "implementation defined" actually mean anything
else than Roedy does with the phrase "platform-dependent". The term
"platform" can unfortunately mean several things, not only OSs and such,
depending on the context it's used in.

An implementation in c++ is defined as any conforming implementation of
c++ provided by a c++ compiler.
I interpreted the phrase platform-dependent to basically mean Hardware
and OS.

AFAIR I could even use different definitions for the primitives within *the
same environment*, depending on the switches I set for the compiler...

Which I had to do in some cases to get the same results of the code when I
moved it between different compilers.

So you could easily say that the primitives in C++ are dependant on even
*more* things than just the "platform"...

Certainly two conforming compilers targeting the same platform could
specify different sizes for primitive types, as long as they meet the
minimum size guarantees.

 

[Oliver Wong]

Bjorn Abelli sez:

No.

What Programming 101 means is "by reference": caller may modify the
parameter, "by value": caller may not modify the parameter.

Like I said, Java may call it "pass by Santa via the chimney" -- that
won't change the fact that all objects in Java are passed by reference
in Comp. Sci. terms.

If you've done Computer Science for any length of time, you know that
the tiniest changes in a statement can cause a large amount of semantic
differences. There's a difference between "reference" and "by reference". A
"reference", in this context, is a certain type of variable (the other type,
in Java, being a primitive scalar). You can say that a variable is a
"reference". You cannot say that a variable is a "by reference". "By
reference" is a manner of passing arguments to a method. Two different
concepts.

I think that's the misunderstanding that Bjorn is referring to.

- Oliver

 

[Roedy Green]

"In C++, you manually manage memory. In Java you don't know for sure
that all finalizers will be run; in C++ you do, because you invoke them
manually." ... "In C++ you call your destructors manually"

This is simply incorrect.

What would you write in its place?

 

[AndyRB]

If it really had been passed "by reference", you would also have had e.g.
the possibility to change the original "reference-holder's" value for a
reference to *another* object, much like you can do in C/C++ and the likes.

References in c++ are not re-bindable, so you can't do what you
describe here and C doesn't have references.

Like java, C is pass by value, although you would usually pass by
pointer in order to simulate pass by reference. In a similar way, IMO
Java gives you reference semantics with respect to the object, but
value semantics with respect to the reference (or anything else) that
is actually passed.

 

[Lasse Reichstein Nielsen]

What Programming 101 means is "by reference": caller may modify the
parameter, "by value": caller may not modify the parameter.

Like I said, Java may call it "pass by Santa via the chimney" -- that
won't change the fact that all objects in Java are passed by reference
in Comp. Sci. terms.

Not the way they are used where I learned computer science. The
difference between pass by value and pass by reference is that pass by
value passes an (r-)value, whereas pass by reference passes an
l-value. Both ways binds the passed value to a local variable in the
called function, and that variable's value can be changed, unless it
is declared final (or whatever the language calls it).

Passing an l-value means passing, e.g., the binding of a variable, as
it exists in the calling scope.

Changing that l-value parameter will change what that variable is
bound to. This change is visible in the calling scope. This is how
ref-parameters work in C#.

Java only passes by value. The r-value of an object expression is a
reference to the object. The value that is passed by value is a
reference, but there is no way to change the binding of a variable
passed as an argument in Java.

/L

 

[AndyRB]

What would you write in its place?

Well in c++ how you allocate an object determines whether you need to
manually deallocate it, so since you already mention the fact that this
choice is automatic in Java, how about...

"In Java, the choice of stack of heap allocation is handled
automatically by the compiler (Sun's javac is not very bright always
using the heap for objects) and garbage collection of unreferenced
objects is automatic. In C++ you have manual control over where objects
are created. The lifetime of objects created on the stack is
automatically controlled, deallocation and destructor automatically
called at a well defined point, this is known as deterministic
destruction. Whereas you have to manually control the lifetime of
dynamically allocated objects."

"In Java you don't know for sure that all finalizers will be run, in
c++ you are guaranteed the destructor will run at the end of the
lifetime of the object. "

The fact that stack based objects are very common in c++ and the fact
that rarely are dynamic based objects left unmanaged is also an
important point, a technique known as RAII (Resource Aquistion is
initialization).

 

[AndyRB]

What would you write in its place?

Well, in c++ how you allocate an object determines whether you need to
manually deallocate it, so since you already mention the fact that this
choice is automatic in Java, how about...

"In Java, the choice of stack of heap allocation is handled
automatically by the compiler (Sun's javac is not very bright always
using the heap for objects) and garbage collection of unreferenced
objects is automatic. In C++ you have manual control over where objects
are created. The lifetime of objects created on the stack is
automatically controlled, i.e. both deallocation and the destructor
call will automatically happen at a well defined point, this is known
as deterministic destruction. Whereas you are required to manually
control the lifetime of dynamically allocated objects."

"In Java you don't know for sure that all finalizers will be run, in
c++ you are guaranteed the destructor will run at the end of the
lifetime of the object."

Also, the fact that stack based objects are very common in c++ and the
fact that rarely are dynmically based objects left unmanaged is also an
important point, this is a very common technique known as RAII
(Resource Aquistion is initialization) and makes a big difference to
how much effort is actually required to "manually" control the lifetime
of an object.

 

[Thomas Hawtin]

"In Java, the choice of stack of heap allocation is handled
automatically by the compiler (Sun's javac is not very bright always
using the heap for objects) and garbage collection of unreferenced

javac cannot use the stack for object storage, because of binary
compatibility constraints.

The latest HotSpot snapshots appears to do escape analysis, to allocate
objects on the heap or not at all, and can put finalisable objects
straight on the finaliser queue without garbage collector involvement.

Tom Hawtin

 

[Roedy Green]

I don't care about the reference, I care about the object behind it.
The important part is that caller code can modify the object I've
passed to it, so the object is a "var" parameter.

You can't pass objects in Java.
You can't pass objects in Java.
You can't pass objects in Java.
You are not in C/Kansas any more. The closest thing you can do to
passing objects is pass references to objects by value.

When you pass primitives by value, copies get made. Any change you
make in the called method has no effect on the caller's variables.

When you pass references by value, copies get made. Any change you
make to the references in the called method have no effect on the
caller's variables.

In other languages, you can have call by reference where the callee
can modify the caller's primitive variables and pointers. You can't
do that in Java. The closest thing to it you can do is changing the
values of fields in objects pointed to by references passed by value
(not to be confused with objects passed by reference).

It does not matter if the object of your desire is a Sex object, the
only way you can pass it is via a Sex reference passed by value. The
concept of directly passing Sex objects does not exist in Java.

C/C++ is much more complicated. You can pass the object, the address
of the object, a pointer to the object, a pointer to a pointer to the
object...

 

[Roedy Green]

"In Java, the choice of stack of heap allocation is handled
automatically by the compiler (Sun's javac is not very bright always
using the heap for objects) and garbage collection of unreferenced
objects is automatic. In C++ you have manual control over where objects
are created. The lifetime of objects created on the stack is
automatically controlled, deallocation and destructor automatically
called at a well defined point, this is known as deterministic
destruction. Whereas you have to manually control the lifetime of
dynamically allocated objects."

I see your point. To me the deallocation of locals is automatic in
every language I have used, so I never thought to explain it.

 

[Roedy Green]

javac cannot use the stack for object storage, because of binary
compatibility constraints.

The latest HotSpot snapshots appears to do escape analysis, to allocate
objects on the heap or not at all, and can put finalisable objects
straight on the finaliser queue without garbage collector involvement.

as does Jet. see http://mindprod.com/jgloss/jet.html

Javac can't do it because there is no way to describe such an on-stack
object allocation in byte code.

If you had a high level the method that ran for hours on end, it might
be wiser to allocate on the heap. Objects on the stack can't be
recycled until the method exits.

I wonder how HotSpot and Jet decide which is the better strategy.

 

[Thomas Hawtin]

I see your point. To me the deallocation of locals is automatic in
every language I have used, so I never thought to explain it.

I believe Simula is an exception to that, with stack frames (apparently)
allocated on the stack. However, it's not a language I have actually used.

Tom Hawtin

 

[Thomas Hawtin]

Javac can't do it because there is no way to describe such an on-stack
object allocation in byte code.

javac would just need to allocate a slot in the frame for each of the
object's fields, and then inline all methods that operate on the former
object. Unfortunately other classes may be altered betwixt compile and
run. Or even after, in the run (there is some code recently added to
Mustang that is complicated by the possibility the Object constructor
may be rewritten).

Tom Hawtin

 

[Bjorn Abelli]

References in c++ are not re-bindable, so you can't do what you
describe here and C doesn't have references.

That's what you get for mixing up lingos for different contexts...

In that sentence I didn't mean "reference" as the explicit C++ construct,
but rather on a more general level as I tried to explain that it was
*possible* to change something at the caller's side, in a way that you can't
in Java.

Like java, C is pass by value, although you would usually
pass by pointer in order to simulate pass by reference.

Well, I said somewhere else that it was many, many years since I programmed
in C/C++... ;-)

void bear::with(me *arg);

If my memory serves me right I believe in C++ I sometimes even used
"references to pointers"... ;-)

// Bjorn A

 

[Monique Y. Mudama]

Who is the document aimed at? Anyone who knows both languages
already has a list of grievances with both languages and would want
them highlighted.

The document is more aimed at someone who knows Java learning C++ or
the reverse to give them a roadmap of the major differences --
things to watch out for. It is not designed to explain the feature
differences in detail. The problem with providing too much detail
is the novice goes away even more baffled that when she started.

Roedy, it just occured to me that you might mention the book

C++ for Java Programmers by Timothy Budd.

I used this book when I transitioned from a Java GUI job to embedded
C++, and it helped a lot. I actually learned C++ before Java, but it
had been a long time since I'd written C++. I tend to think in terms
of Java inheritance, not C++.

 

[Roedy Green]

Roedy, it just occured to me that you might mention the book

C++ for Java Programmers by Timothy Budd.

thanks. Now added to http://mindprod.com/jgloss/cpp.html

 

[Dimitri Maziuk]

Lasse Reichstein Nielsen sez:

Not the way they are used where I learned computer science. The
difference between pass by value and pass by reference is that pass by
value passes an (r-)value, whereas pass by reference passes an
l-value.

OK, this I can live with. However, the way I used "reference" in
the above is "an object containing information which refers to
data elsewhere" (wikipedia definition).

Getting back to Java vs C++, taking a look at what asssignment
operator does to C++ reference, in view of the above definition,
can be enlightening.

Dima

 

[Roedy Green]

OK, this I can live with. However, the way I used "reference" in
the above is "an object containing information which refers to
data elsewhere" (wikipedia definition).

In Java, reference has a very specific meaning, and that Wikipedia
definition does not fit.

A references is not an object. It is a primitive. It does refer to
information "elsewhere" but Java does not really have much of a notion
of "where" things are. That notion is left very vague and up to the
implementor. A reference could refer to the object it is a part of.
So the notion of elsewhere is not quite the best way to describe it.

Personally I don't know how you could begin to think about references
without the knowledge of how they work at the machine code level, but
thousands of people do it every day.

Even the heap/stack distinction is pretty fuzzy so long a few scope
properties are fulfilled.

 

[Dimitri Maziuk]

Roedy Green sez:

In Java, reference has a very specific meaning, and that Wikipedia
definition does not fit.

A references is not an object.

"Object" in that definition means "thingy", not "instance of a class".
I thought of spelling it out, but then I thought it's obvious enough
from context.

....It is a primitive. It does refer to

information "elsewhere" but Java does not really have much of a notion
of "where" things are. ....
Even the heap/stack distinction is pretty fuzzy so long a few scope
properties are fulfilled.

Precisely. These things make Java very different from C++. I'd start my
"Java vs C++" list with
1. Terminology: same terms often mean different things in Java and C++.
For example,
1.1. "reference" in Java means "object reference" and is a primitive
data type (kinda like C++ pointer without address arithmetics).
"Reference" in C++ mean "a handle": something through which you
access the underlying data. C++ makes no claims as to how a
reference is actually implemented. All operations on C++ reference
operate on the underlying object (in Java, assignment operator
works on the "object reference" itself, while method calls work on
the object).
1.2. "interface" in Java is a means to specify behaviour (and not
really a "better way to multiple inheritance", BTW), what in OO
is usually called "a protocol". C++ does not have interfaces as such,
so in C++ "interface" can refer to class's header file, binary interface
(esp. name mangling), "abstract base class", or used in the original
OO meaning of "binding contract between author and user of the class".
1.3. "immutable" in Java refers to object that have (seldom documented)
property: once created, they cannot be modified. In C++ "immutable"
usually refers to pointers or references that are declared "const"
(that means you can't change the data pointed/referred to via that
particular pointer/refedrence).
1.4. Etc.

Dima

 

[Stefan Ram]

1. Terminology: same terms often mean different things in Java and C++.

It is also instructive to look up the meaning of "object" and
"variable" in ISO/IEC 14882:2003(E) and compare it with the
definitions of the same terms in "The Java Language
Specification, Third Edition".