Differences between C++ and Java

R

Roedy Green

"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.

If you are trying to get your head around ideas like references,
objects, call by reference, call by value etc. you have to be very
picky about the way you use terminology.

You are not talking to someone who already understands, and hence will
accurately sort out your ambiguities. They are hopelessly lost and
will be guaranteed to misinterpret every possible ambiguity, and even
statements that are not ambiguous.

I wonder if perhaps the best way to explain all this would be with a
short course on how JVM stack machine works. Gosling dreams about the
JVM, not Java. The JVM is ever so much more logical than Java.
 
O

Oliver Wong

Roedy Green said:
If you are trying to get your head around ideas like references,
objects, call by reference, call by value etc. you have to be very
picky about the way you use terminology.

You are not talking to someone who already understands, and hence will
accurately sort out your ambiguities. They are hopelessly lost and
will be guaranteed to misinterpret every possible ambiguity, and even
statements that are not ambiguous.
Agreed.


I wonder if perhaps the best way to explain all this would be with a
short course on how JVM stack machine works. Gosling dreams about the
JVM, not Java. The JVM is ever so much more logical than Java.

When I used to tutor students in Java, I usually tried to explain Java
references by showing what would happen under the hood in an abstract RAM
machine. Imagine a machine with infinite memory, each cell in the memory
labelled 0, 1, 2, etc. Once the students were comfortable with this, you
could just explain references being the analog of cells containing the
address of other cells, and they'd usually get the concept pretty quickly.

- Oliver
 
D

Dimitri Maziuk

Roedy Green sez:
....
I wonder if perhaps the best way to explain all this would be with a
short course on how JVM stack machine works.

I'd second that.

BTW, is your website off-line or is it just me?
-- I cannot get to mindprod.com since yesterday.

Dima
 
R

Roedy Green

BTW, is your website off-line or is it just me?
-- I cannot get to mindprod.com since yesterday.

It is in the process of being moved to a new site with 10 times faster
access. My ISP's site is down too, so I gather there has been a snag.
I don't like to jitter since my ISP has been unusually generous over
the years.
 
T

Thomas G. Marshall

Oliver Wong said something like:

....[rip]...
When I used to tutor students in Java, I usually tried to explain
Java references by showing what would happen under the hood in an
abstract RAM machine. Imagine a machine with infinite memory, each
cell in the memory labelled 0, 1, 2, etc. Once the students were
comfortable with this, you could just explain references being the
analog of cells containing the address of other cells, and they'd
usually get the concept pretty quickly.

Yes! A form of memory location/pointer. That is /precisely/ how it should
be taught to a very junior person, and the precise mechanism I use!!!!!!

Good for you for using this.
 
T

Thomas G. Marshall

Roedy Green said something like:
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.


Huh? No it isn't.

http://java.sun.com/docs/books/jls/second_edition/html/typesValues.doc.html#9122

<quote JLS2>
A primitive type is predefined by the Java
programming language and named by its
reserved keyword (§3.9):
PrimitiveType:
NumericType
boolean

NumericType:
IntegralType
FloatingPointType

IntegralType: one of
byte short int long char

FloatingPointType: one of
float double
</quote>


....[rip]...
 
T

Thomas G. Marshall

Dimitri Maziuk said something like:
Bjorn Abelli sez:

Yes.


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.

No.

Sorry to add to this so late, but even when I took the first tier
programming course in my computer science degree in college in 1982, they
tried to be very clear about this. That C, for example, is pass by value
/only/. I didn't see why the term was defined as it is, mostly because I
didn't care about it, until much later.

As has been said in many different ways, particularly in these java forums,
PbR means that modifying the formal parameter will result in a modification
of the actual parameter. Java doesn't allow that and is .: PbV.
 
T

Thomas G. Marshall

Chris Uppal said something like:
FWIW, the i86 instructions and register set don't really correspond to the
chip's architecture -- there's another layer of emulation in there. The
IA-32 architecture is just as "virtual" as the JVM (although of a very
different design, and low-level rather than high-level).

Modern software

/All/ software.
sits on top of an N-level stack of interpretation[*]; there's
not (IMO) much point in talking about whether something is emulated or
virtual -- everything is both ;-)

Smiley taken, but you're correct, smiley or no.

No matter how simple the cpu, each component of it can be broken down into a
number of "things". The list of the modern day hooey that could be these
"things" goes far beyond my hardware understanding. In the old days, it
might be comprised of microcode, mini-logic arrays, and gates.

What we have here is yet another abstraction ladder. There is no clear
distinction as to what is really the cpu instruction:

The CPU add instruction
The CPU parts responsible for the add
The electron propagation responsible for them parts
The quark spin and positioning responsible for the electron
propagation
(more hooey over my head)

In java's case we just continue the stack skyward

Java add
program code responsible for the java add
The CPU instructions responsible for that program code
The CPU parts responsible for those instructions
The electron propagation responsible for them parts
The quark spin and positioning responsible for the electron
propagation
(more hooey over my head)

Wha'ever.

([*] Taking JITing to be just another interpretation technique for these
purposes.)

-- chris
 
T

Thomas G. Marshall

AndyRB said something like:

....[rip]...
"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. "

I understand what you are saying here, but in c++ you can legally only
point to an object or one past the end of a object, otherwise you have
undefined behaviour.


That is correct, but by "legally" you mean simply compliant with the
standard. FWIW, non-compliant C++ is still C++. From C++'s point of view
{chuckle} it *does* allow you point "anywhere in the address space". I have
had a similar argument about all this before, regarding Std. C.

Std C has the precisely identical requirement about where a pointer can go
and remain trustworthy. At the beginning or one past: in fact the C
specification actually uses the term "object" as well. The only problem
with all this is that you cannot write malloc() in Std C, nor can you write
any device driver I can think of, but they are still regarded as being coded
in C.

As such, when discussing the abilities of a language, in the C++ case Roedy
said it properly.


....[rip]...
 
D

Dimitri Maziuk

Thomas G. Marshall sez:
....
Sorry to add to this so late, but even when I took the first tier
programming course in my computer science degree in college in 1982, they
tried to be very clear about this. That C, for example, is pass by value
/only/. I didn't see why the term was defined as it is, mostly because I
didn't care about it, until much later.

As has been said in many different ways, particularly in these java forums,
PbR means that modifying the formal parameter will result in a modification
of the actual parameter. Java doesn't allow that and is .: PbV.

Sheesh.

void myfunc( MyObj o ) {
o.sefFoo( newfoo );
}

How is that not modifying the actual instance of MyObj via "o"?

What Java doesn't allow is doing "o = otherobj;" and having
that stick after myfunc() returns. That's because "o" is
"object reference": a special data type that is similar, but
not quite the same as "reference" in "pass-by-reference".

There's a proper tool for every job and the one for teaching
1st tier programming is Pascal. Where the difference between
by-value parameter and "var" parameter does not come with
"pointer itself is by-value, but the data pointed to is not"
baggage of C-derived languages.

Dima
 
A

AndyRB

Thomas said:
AndyRB said something like:

...[rip]...
"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. "

I understand what you are saying here, but in c++ you can legally only
point to an object or one past the end of a object, otherwise you have
undefined behaviour.


That is correct, but by "legally" you mean simply compliant with the
standard.
No, in this specific case I mean writing erroneous code which is
explicitly stated as invoking undefined behaviour.
FWIW, non-compliant C++ is still C++.
non-compliant c++ code or non-compliant implementation?
If you are talking about code that invokes undefined behaviour (which
is the kind of code Roedy described in his statement) then what you
have is erroneous c++ code. The problem is many newbies (quite possibly
Roedy's target audience) are ignorant of undefined behaviour and think
that if their c++ code simply compiles then it must be valid c++. In
reality the standard places no requirements on such code whatsoever.
From C++'s point of view
{chuckle} it *does* allow you point "anywhere in the address space".

C++ allows you to map an integer address to a pointer (mapping is
implementation defined).

However:
int i;
int * p = &i;
++p; //Ok p points one past i
++p; //undefined behaviour.

My point is specifically concerning pointer arithmetic, which Roedy
mentioned explicitly in his statement.

I have
had a similar argument about all this before, regarding Std. C.

Std C has the precisely identical requirement about where a pointer can go
and remain trustworthy. At the beginning or one past: in fact the C
specification actually uses the term "object" as well. The only problem
with all this is that you cannot write malloc() in Std C, nor can you write
any device driver I can think of, but they are still regarded as being coded
in C.

Such very low-level code usually falls under the category of
implementation-defined behaviour and relies on guarantees given by the
implementation, but that is very different from undefined behaviour.
As such, when discussing the abilities of a language, in the C++ case Roedy
said it properly.

No, in c++ you cannot use pointer arithmetic to point to anywhere
within the address space, it is explicitly undefined behaviour
(consider a segmented memory model).
 
C

Chris Uppal

AndyRB said:
No, in c++ you cannot use pointer arithmetic to point to anywhere
within the address space, it is explicitly undefined behaviour

Perhaps a better way to phrase the underlying point is that C++ allows you to
write pointer-manipulation code which results in undefined behaviour.

C++ does. Java does not. Significant difference.

-- chris
 
T

Thomas G. Marshall

Dimitri Maziuk said something like:
Thomas G. Marshall sez:
...

Sheesh.

void myfunc( MyObj o ) {
o.sefFoo( newfoo );
}

How is that not modifying the actual instance of MyObj via "o"?

Java /cannot/ and /is not/ modifying o which is the formal parameter. It is
modifying the object that o points to.

What Java doesn't allow is doing "o = otherobj;" and having
that stick after myfunc() returns. That's because "o" is
"object reference": a special data type that is similar, but
not quite the same as "reference" in "pass-by-reference".

You're half correct and botched the conclusion. I'm afraid you're still not
understanding this, particularly if you say something like that.

Dimitri, let's pretend that we have a fully PbR java language and we try the
following:

void method(Object o)
{
o = null;
}

Object obj = new Object();
method(obj);
// obj is now null here in this mythical PbR java language.

The fact that it is an object reference means nothing!

....[rip]...
 
A

AndyRB

Chris said:
Perhaps a better way to phrase the underlying point is that C++ allows you to
write pointer-manipulation code which results in undefined behaviour.

C++ does. Java does not. Significant difference.

-- chris

Yes, I think you are right and it certainly is one of the biggest
differences.

The point could be generalized regarding the ability to write undefined
behaviour in general with pointer arithmetic and, say, dereferencing a
null pointer as an example? Other issues that have to be considered
when coding c++ such as unspecified and implementation defined
behaviour, could also be noted.
 
T

Thomas G. Marshall

AndyRB said something like:
Thomas said:
AndyRB said something like:
....[rip]...

No, in c++ you cannot use pointer arithmetic to point to anywhere
within the address space, it is explicitly undefined behaviour
(consider a segmented memory model).

Of course! But that happens /after/ the compiler accepts the attempt to set
the pointer [anywhere] and when that part of the code is executed. Never
stated that you wouldn't often have trouble with it, that's to be expected,
particularly with protected memory models. And my usage of the term
non-compliant C++ code to include code specifically mentioned by the C++
specification as resulting in undefined is consistent with common usage.
You certainly should not shudder at such usage when someone says:

Your code does not comply with the C++ specification.
 
T

Thomas G. Marshall

Chris Uppal said something like:
Perhaps a better way to phrase the underlying point is that C++
allows you to write pointer-manipulation code which results in
undefined behaviour.

You're probably right. /Allows you to/, is what I consider to be closest to
what I am saying.
 
R

Roedy Green

What Java doesn't allow is doing "o = otherobj;" and having
that stick after myfunc() returns. That's because "o" is
"object reference": a special data type that is similar, but
not quite the same as "reference" in "pass-by-reference".

The point is words mean what people decide they mean. The Java
community through consensus came to define call by reference and call
by value in such a way that Java always passes by value. Everything
makes sense if you are consistent about this definition.

If you change the definitions, then you get chaos. That is why the
definitions were frozen long before you came along. Had you been here
a decade or so ago, perhaps the definitions today would be different.

It does not really matter what the definitions are. What matters is
consistency and accuracy. You are just stirring up confusion where
none need exist.

Nobody is claiming a method cannot modify the caller's objects via the
copies of references it is passed. They are just saying that is not
what Javites mean by pass by reference.

Please at least read the JVM spec and also study how parameters are
passed in various language at the machine code level before you
continue with your crusade. Then you could at least understand
rationale behind the Java definition.

What you are doing is like walking into a group of mathematicians and
letting them they got the terms "integer" and "natural number"
backwards and they had better shape up.
 
R

Roedy Green

The problem is many newbies (quite possibly
Roedy's target audience) are ignorant of undefined behaviour and think
that if their c++ code simply compiles then it must be valid c++.

That is not the issue. The issue is whether there are mechanisms to
detect the error or you simply get undefined results.

Think for example writing C code where you failed to initialise a
variable. This was legal. Most of the time it was initialised to 0.
But sometimes it was not, leading to a need for a timeout in a padded
cell. It STRONGLY matters if the compiler/run time can detect the
error.

It is almost irrelevant if the given code is technically legal.
 
T

Thomas G. Marshall

Thomas G. Marshall said something like:
Dimitri Maziuk said something like:

Java /cannot/ and /is not/ modifying o

Well, a quick rephrase, of course to be consistent with the definition I've
already provided.

It /can/ alter the formal parameter o, but doing so cannot touch the actual
parameter.

The important point that needs to be driven home here is that the parameter
isn't technically an instance at all. It is a reference (pointer) to an
instance.

which is the formal parameter.
It is modifying the object that o points to.

....[rip]...
 
T

Thomas G. Marshall

Roedy Green said something like:
The point is words mean what people decide they mean. The Java
community through consensus

Hardly. This wasn't a bunch of folks getting together over cards. You're
making this sound like an oddity in phrasing.

came to define call by reference and call
by value in such a way that Java always passes by value.

Not just the java community. Both my computer science programming 401
course in 1982, and my later compiler design course were insistant upon
this, using C as their example. I had to research this and iron this sucker
out when teaching other engineers java. Unfortunately, there are few "last
word authorities" on the subject, but I can tell you that the vast majority
of language/compiler design folks I've spoken to, perhaps 5 :) , all agree.
In java the parameter is a reference, and alterring that reference within
the method does not touch the actual parameter, and java is therefore PbV.
 

Ask a Question

Want to reply to this thread or ask your own question?

You'll need to choose a username for the site, which only take a couple of moments. After that, you can post your question and our members will help you out.

Ask a Question

Members online

Forum statistics

Threads
473,744
Messages
2,569,483
Members
44,903
Latest member
orderPeak8CBDGummies

Latest Threads

Top