Differences between C++ and Java

java-programmer, Differences between C++ and Java On 1 Dec 2005 10:25:38 -0800, "AndyRB" <email***@***.com> wrote,
quoted or indirectly quoted someone who said :

>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.
--
Canadian Mind Products, Roedy Green.
http://mindprod.com Java custom programming, consulting and coaching.

java-programmer >> Differences between C++ and Java On 1 Dec 2005 10:25:38 -0800, "AndyRB" <email***@***.com> wrote,
quoted or indirectly quoted someone who said :

>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.
--
Canadian Mind Products, Roedy Green.
http://mindprod.com Java custom programming, consulting and coaching.

java-programmer >> Differences between C++ and Java Thomas G. Marshall said something like:
> Dimitri Maziuk said something like:
>> 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"?
>
> 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]...

java-programmer >> Differences between C++ and Java Roedy Green said something like:
> On Thu, 1 Dec 2005 17:35:55 +0000 (UTC), Dimitri Maziuk
> <email***@***.com> wrote, quoted or indirectly quoted someone who said :
>
>>
>> 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

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.

java-programmer >> Differences between C++ and Java
Thomas G. Marshall wrote:
> AndyRB said something like:
> > Thomas G. Marshall wrote:
> >> 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.

Who says that the compiler accepts the code and that the code even gets
executed.
It is undefined behaviour so technically you cannot assume anything
about what will happen or even what will be attempted.

java-programmer >> Differences between C++ and Java
"AndyRB" <email***@***.com> wrote in message
news:email***@***.com...
>
> Thomas G. Marshall wrote:
>>
>> 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.
>
> Who says that the compiler accepts the code and that the code even gets
> executed.
> It is undefined behaviour so technically you cannot assume anything
> about what will happen or even what will be attempted.

While I haven't read the C++ spec, based on my experience of reading
specifications for other languages, generally when they say "undefined
behaviour", they mean "undefined runtime behaviour". It is almost always
very well defined whether or not something will get accepted by the
compiler.

In other words, the "behaviour" they are referring to is the behaviour
of the program you're writing, not the behaviour of the compiler.

- Oliver

java-programmer >> Differences between C++ and Java Bjorn Abelli said something like:
> "AndyRB" wrote...
>> Bjorn Abelli wrote:
>>
>>> 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.
>
> 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"... ;-)

All manner of crap has been used in C++ that just boggles
the^H^H^Heveryone's mind.

--
Onedoctortoanother:"Ifthisismyrectalthermometer,wherethehell'smypen???"

java-programmer >> Differences between C++ and Java AndyRB said something like:
> Thomas G. Marshall wrote:
>> AndyRB said something like:
>>> Thomas G. Marshall wrote:
>>>> 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.
>
> Who says that the compiler accepts the code and that the code even gets
> executed.
> It is undefined behaviour so technically you cannot assume anything
> about what will happen or even what will be attempted.

We're going woefully astray here. But for yucks, I'll answer this part:
Undefined behavior is /always/ a definition of what happens at run time.
The compiler is in complete control of itself, and such a notion need not
exist at compile time. It is not, for example, ok for the compiler to spit
how "holy @#$% !!!" just because the behavior of an idiom/construct is
listed undefined in the specification.

--
Onedoctortoanother:"Ifthisismyrectalthermometer,wherethehell'smypen???"

java-programmer >> Differences between C++ and Java Roedy Green <email***@***.com> wrote:
> 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.

I'd modify that. The computer science field has come to define those
words in certain ways. Although there is a small step involved in apply
the definition to each individual language (namely, defining the term
"assignment operation" in the context of that language), the definition
is consistent and widely accepted at least among those who practice
language design and theory.

The Java community has come to understand that definition as it applies
to the Java programming language.

--
www.designacourse.com
The Easiest Way To Train Anyone... Anywhere.

Chris Smith - Lead Software Developer/Technical Trainer
MindIQ Corporation

java-programmer >> Differences between C++ and Java Thomas G. Marshall wrote:
>
> We're going woefully astray here. But for yucks, I'll answer this part:
> Undefined behavior is /always/ a definition of what happens at run time.
> The compiler is in complete control of itself, and such a notion need not
> exist at compile time. It is not, for example, ok for the compiler to spit
> how "holy @#$% !!!" just because the behavior of an idiom/construct is
> listed undefined in the specification.

So, are these features of C++ not undefined behaviour (if my memory serves):

o Platform dependent restrictions on the length of identifiers.

o Platform dependent restrictions on the depth of recursion of
template instantiation.

o Platform dependent #includes of one C++ standard header file from
another (not allowed for the C headers).

o Spitting out of platform dependent warnings.

Tom Hawtin
--
Unemployed English Java programmer
http://jroller.com/page/tackline/

java-programmer >> Differences between C++ and Java Thomas G. Marshall wrote:
> AndyRB said something like:
> > Thomas G. Marshall wrote:
> >> AndyRB said something like:
> >>> Thomas G. Marshall wrote:
> >>>> 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.
> >
> > Who says that the compiler accepts the code and that the code even gets
> > executed.
> > It is undefined behaviour so technically you cannot assume anything
> > about what will happen or even what will be attempted.
>
>
> We're going woefully astray here. But for yucks, I'll answer this part:
> Undefined behavior is /always/ a definition of what happens at run time.
> The compiler is in complete control of itself, and such a notion need not
> exist at compile time. It is not, for example, ok for the compiler to spit
> how "holy @#$% !!!" just because the behavior of an idiom/construct is
> listed undefined in the specification.

Undefined behaviour does not have to be diagnosed at compile-time, but
it is very much OK for a conforming compiler to spit out "holy @#$%
!!!" if it encounters a construct that is undefined behaviour.

>From the c++ standard definition...
"[Note: permissible
undefined behavior ranges from ignoring the situation completely with
unpredictable results, to
behaving during translation or program execution in a documented manner
characteristic of the environment
(with or without the issuance of a diagnostic message), to terminating
a translation or execution
(with the issuance of a diagnostic message)."

Note the explicit references made to translation in the above
definition.

>
>
>
> --
> Onedoctortoanother:"Ifthisismyrectalthermometer,wherethehell'smypen???"

java-programmer >> Differences between C++ and Java Oliver Wong wrote:
> "AndyRB" <email***@***.com> wrote in message
> news:email***@***.com...
> >
> > Thomas G. Marshall wrote:
> >>
> >> 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.
> >
> > Who says that the compiler accepts the code and that the code even gets
> > executed.
> > It is undefined behaviour so technically you cannot assume anything
> > about what will happen or even what will be attempted.
>
> While I haven't read the C++ spec, based on my experience of reading
> specifications for other languages, generally when they say "undefined
> behaviour", they mean "undefined runtime behaviour". It is almost always
> very well defined whether or not something will get accepted by the
> compiler.
So you are making assumptions about c++ based on the specifications of
entirely different languages?
>
> In other words, the "behaviour" they are referring to is the behaviour
> of the program you're writing, not the behaviour of the compiler.

>From the /C++/ standard definition...
"[Note: permissible
undefined behavior ranges from ignoring the situation completely with
unpredictable results, to
behaving during translation or program execution in a documented manner
characteristic of the environment
(with or without the issuance of a diagnostic message), to terminating
a translation or execution
(with the issuance of a diagnostic message)."

Note the explicit references made to translation in the definition
above.
>
> - Oliver

java-programmer >> Differences between C++ and Java
Roedy Green wrote:
> On 1 Dec 2005 10:25:38 -0800, "AndyRB" <email***@***.com> wrote,
> quoted or indirectly quoted someone who said :
>
> >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.
and what sounds like undefined behaviour. Uninitialised variables are
legal, using uninitialised variables is undefined...however, I don't
think this affects the point I think you are trying to make.

>It STRONGLY matters if the compiler/run time can detect the
> error.
I don't think I have ever said anything to the contrary?
>
> It is almost irrelevant if the given code is technically legal.

It is irrelevant as far as erroneous code is erroneous, but that was
not the point I was making.

The point I am trying to make is that you can't attach expectations to
undefined behaviour, so what I am saying is that a statement along the
following lines is incorrect:

In c++ you can write <replace with some code that is undefined
behaviour> in order to <replace with some expected output>.

If the code is undefined behaviour you can say absolutely nothing about
what the code should do. It is on that basis that I said some of your
statements (e.g. pointer arithmetic)were incorrect.

> --
> Canadian Mind Products, Roedy Green.
> http://mindprod.com Java custom programming, consulting and coaching.

java-programmer >> Differences between C++ and Java
"AndyRB" <email***@***.com> wrote in message
news:email***@***.com...
> Oliver Wong wrote:
>> While I haven't read the C++ spec, based on my experience of reading
>> specifications for other languages, generally when they say "undefined
>> behaviour", they mean "undefined runtime behaviour". It is almost always
>> very well defined whether or not something will get accepted by the
>> compiler.
> So you are making assumptions about c++ based on the specifications of
> entirely different languages?

Yes. Sort of like when I encounter a new programming language and see
the statement "x = y + z;", I assume that the + is an operator (and not,
say, a variable name) that does something semantically equivalent to
"addition" on the "y" and "z", which I assume are variable names (and not,
say, operators). This interpretation is so widespread, it almost seems like
a defacto standard, and from a utilitarian perspective, it is MORE useful to
just make that assumption, and then correct yourself when you find out that
you are wrong, than to sort of be blocked from proceeding further and
acknowledging that you don't actually really know what the statement means.

>>
>> In other words, the "behaviour" they are referring to is the
>> behaviour
>> of the program you're writing, not the behaviour of the compiler.
>
>>From the /C++/ standard definition...
> "[Note: permissible
> undefined behavior ranges from ignoring the situation completely with
> unpredictable results, to
> behaving during translation or program execution in a documented manner
> characteristic of the environment
> (with or without the issuance of a diagnostic message), to terminating
> a translation or execution
> (with the issuance of a diagnostic message)."
>
> Note the explicit references made to translation in the definition
> above.

Noted. I'm very surprised that this is the stance on what is accepted
when something is said to have "undefined behaviour", but if that's what it
says, so be it. I stand corrected.

- Oliver

java-programmer >> Differences between C++ and Java Roedy Green wrote:
> 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?
>
> --
> Canadian Mind Products, Roedy Green.
> http://mindprod.com Java custom programming, consulting and coaching.

Hi,

You've covered many good points, in addition most of my points aren't
language related per se but they are certainly important and an
inevitable part of using each language.

Culture.
Java has a culture of "let's make it easy and cool to use" while C++'s
culture is "hey if you can't hang with the big boys, that's your
problem (... try VB)".

Java: "You need an API, yea, we'll build it, you can have it ... for
free" ;-)
C++: "You need an API, great go build it yourself ... or buy it" ;-|

Growth.
JCP - moves pretty quickly. New JDK every year.
ANSI C++ - moves slowly, to "gc" or "not to gc"... meantime the world
has moved on.

Support.
Sun makes huge effort to sign everyone up for Java support (remember
those days).
C++ leaves participation open to happen-stance.

JDBC is just one fruit of that almost unanimous and uniform support,
while in C++ talking to databases is still on a case by case basis.

Enterprise integration. Java has J2EE, C++ say's "that's your problem
not ours".

C++: A case of a language and a compiler, *all* the rest is up to you.
Java: We'll make all the pieces of the jigsaw puzzle and we'll make
them fit, you only need to make the app.

Style.
Java encourages "ease" thus clarity thus verbosity, happyTyingFolks (
).
C++ is terse. htf ( ). (Of course that's only a cultural tendency not
an intrinsic language feature..)

Java: A class must be in a file of the same name. File location must
match package structure.
C++: Put it where you want, name it how you want (=mess).

Cheers.

java-programmer >> Differences between C++ and Java AndyRB said something like:
> Thomas G. Marshall wrote:
>> AndyRB said something like:
>>> Thomas G. Marshall wrote:
>>>> AndyRB said something like:
>>>>> Thomas G. Marshall wrote:
>>>>>> 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.
>>>
>>> Who says that the compiler accepts the code and that the code even gets
>>> executed.
>>> It is undefined behaviour so technically you cannot assume anything
>>> about what will happen or even what will be attempted.
>>
>>
>> We're going woefully astray here. But for yucks, I'll answer this part:
>> Undefined behavior is /always/ a definition of what happens at run time.
>> The compiler is in complete control of itself, and such a notion need not
>> exist at compile time. It is not, for example, ok for the compiler to
>> spit
>> how "holy @#$% !!!" just because the behavior of an idiom/construct is
>> listed undefined in the specification.
>
> Undefined behaviour does not have to be diagnosed at compile-time, but
> it is very much OK for a conforming compiler to spit out "holy @#$%
> !!!" if it encounters a construct that is undefined behaviour.
>
>> From the c++ standard definition...
> "[Note: permissible
> undefined behavior ranges from ignoring the situation completely with
> unpredictable results, to
> behaving during translation or program execution in a documented manner
> characteristic of the environment
> (with or without the issuance of a diagnostic message), to terminating
> a translation or execution
> (with the issuance of a diagnostic message)."
>
> Note the explicit references made to translation in the above
> definition.

Hmmm ok, thanks. I'll have to ponder on this---IMO there's a nuance to this
that /still/ doesn't seem quite right in this thread's context. But in any
case, Chris Uppal rephrased it properly already.

--
Whyowhydidn'tsunmakejavarequireanuppercaselettertostartclassnames....

java-programmer >> Differences between C++ and Java Roedy Green sez:
...
> Please at least read the JVM spec and also study how parameters are
> passed in various language

I have, and I much prefer Delphi language guide that says object
references are "pointers that are automatically dereferenced" in
the "objects" section and that if you wnat to, you can var any
formal parameter
procedure myfunc( var o:Myobj )
(in the "methods" section).

JLS says that there are three "reference types" and that reference types
are *not* primitive types. It says that "reference values" are pointers
to objects. Then you trace down the three "reference types" and work out
that in the end they're all instantiated as objects, so "reference values"
is what you're interested in.

In 2.10 JLS says that for every parameter, a new variable is created and
initialized when method is invoked. Thankfully, I know enough about
stack-based languages to understand what they mean by that.

So it's the same as Delphi sans var parameters and clarity of documentation.

> ... before you
> continue with your crusade.

What crusade? -- I'm just keepin' up a polite conversation. Prompted
by your statement that "Java references point to the beginnings of
objects, in C++ you can do pointer arithmetics..." It's bad, OK?

Because

1. Java "reference values (often just _references_)" are pointers
to objects and there are only two things you can do with them: point
one to an object and access object's members via it (basically; there's
also comparisons which may or may not be done by object's members,
instanceof and string concatenation). They don't point to "the beginnings
of objects" -- that's simply meaningless in Java context -- they point
to objects.

2. Unlike Java reference values, C pointers are just memory addresses.
Modern compilers give you syntactic icing on top, like remembering the
type of data poined to and various cast operations, but you're pretty
much free to discard all that sugar and do whatever you want with them
(e.g. work out the address of the second byte in the third field of the
fifth element of an array of records. Sorry, structs.).

C++ also has references, in addition to pointers. C++ references are
nothing at all like Java reference values. They are more like references
in Comp. Sci. definition. You cannot re-point a reference and whatever
you do to the reference you're doing to underlying data.

Both pointers and refences in C++ can point to/reference any data
type (including pointers), not just objects.

Dima
--
We're part of that admittedly-too-small group that is trying to save
the human race from itself. With any luck, we'll fail abjectly and
the cockroaches will win out.
-- Mike Andrews

java-programmer >> Differences between C++ and Java On Sat, 3 Dec 2005 19:41:51 +0000 (UTC), Dimitri Maziuk
<email***@***.com> wrote, quoted or indirectly quoted someone who said :

>> ... before you
>> continue with your crusade.
>
>What crusade?

your crusade to change Java's definition of call by value.
--
Canadian Mind Products, Roedy Green.
http://mindprod.com Java custom programming, consulting and coaching.

java-programmer >> Differences between C++ and Java Dimitri Maziuk said something like:

...[rip]...

> 1. Java "reference values (often just _references_)" are pointers
> to objects and there are only two things you can do with them: point
> one to an object and access object's members via it (basically; there's
> also comparisons which may or may not be done by object's members,
> instanceof and string concatenation). They don't point to "the beginnings
> of objects" -- that's simply meaningless in Java context -- they point
> to objects.

While this is obviously correct, I believe that the layman explanation of
references pointing to solely the beginnings of objects is not a terrible
one. In C, for example, when you have a pointer to a struct, you have a
pointer to it's first location in memory. So it's an understood programming
idiom.

In java, you cannot take the address of, say, the third int in an object.

Hmmm, I'm guessing here, but a C99 purist might be able to argue that the C
pointer to a struct is not to the first location of a struct but to the
struct itself, because you cannot do anything legal but dereference the
entire struct or sub components of it with "->". You can *obviously* do
much more, but it all would require modifying the pointer by casting it to
something else. {shrug}. If so, I don't see much the point in pedantically
pointing it out.

On the flip side of all this, I don't believe that the point of C and Java's
PbV is a pedantic one, but this reopens a (hopefully) dead issue in this
thread.

...[rip]...

> C++ also has references, in addition to pointers. C++ references are
> nothing at all like Java reference values.

No one is contesting that. Even the JLS refers to the reference as a
pointer.

...[rip]...

--
"I don't want FOP, God dammit! I'm a DAPPER DAN MAN!"

java-programmer >> Differences between C++ and Java Dimitri Maziuk <email***@***.com> wrote:
> I have, and I much prefer Delphi language guide that says object
> references are "pointers that are automatically dereferenced"

And that's Delphi. It doesn't make sense to say that in Java. In Java,
a reference is only dereferenced if you apply an operation that
dereferences it. Those operations include the "." and "[]" symbols, and
Java 1.5's unboxing conversions. Otherwise, there is no dereferencing
that takes place.

> JLS says that there are three "reference types" and that reference types
> are *not* primitive types. It says that "reference values" are pointers
> to objects.

Well, to be precise, it says that a reference value is either a pointer
to an object, or null.

> Then you trace down the three "reference types" and work out
> that in the end they're all instantiated as objects, so "reference values"
> is what you're interested in.

I'm a little lost by your use of words here. References are just
values. Creating a reference doesn't necessarily imply instantiating an
object. You seem to be talking about something that you call
instantiating a reference type... for which I can't find any logical
meaning. In any case, it's not normal Java terminology.

> In 2.10 JLS says that for every parameter, a new variable is created and
> initialized when method is invoked. Thankfully, I know enough about
> stack-based languages to understand what they mean by that.

I see that language in 4.12.3 in the JLS 3rd edition, and 4.5.3 in the
JLS 2nd edition. Are you sure you're reading the same JLS as the rest
of us?

In any case, I don't know whether you understand this or not. In any
case, this language in the spec doesn't imply a stack. It may or may
not be implemented with the CPU stack (though it obviously is most of
the time for performance reasons). It is similar to, but not quite, an
implementation of the generic computer science concept of stacks --
differing only in that local variables within the current stack frame
may be accessed in any order.

It means just what it says. Every time a method is called, the actual
parameters are copied into the formal parameters, which function as
separate variables. This is pretty close to exactly the definition of
pass by value, as it turns out.

> So it's the same as Delphi sans var parameters and clarity of
> documentation.

I don't know much about Delphi, but the language above about references
being automatically dereferenced suggests that it's not exactly the
same. If use of a reference as an lvalue in Delphi modifies the object
and not the reference, then it is different in precisely the way that is
needed in order to make Delphi qualify as pass by reference in a way
that Java does not.

Incidentally, if you're look for documentation that makes intuitive
sense to you, then the language spec may not be the place the look.
There are good books on Java, including for example Bruce Eckel's which
is free online. However, if you're looking for precise definition of
language behavior, the spec is the place to look.

> What crusade? -- I'm just keepin' up a polite conversation. Prompted
> by your statement that "Java references point to the beginnings of
> objects, in C++ you can do pointer arithmetics..." It's bad, OK?

I agree that the statement you're quoting is a poor description. It
mixes implementation with specification (in much the same way as the
stack comment above).

> 2. Unlike Java reference values, C pointers are just memory addresses.
> Modern compilers give you syntactic icing on top, like remembering the
> type of data poined to and various cast operations, but you're pretty
> much free to discard all that sugar and do whatever you want with them
> (e.g. work out the address of the second byte in the third field of the
> fifth element of an array of records. Sorry, structs.).

I'm sure someone will jump in and point out that the above is only true
if you're willing to achieve undefined behavior according to the C
standard. Nevertheless, your point remains true.

--
www.designacourse.com
The Easiest Way To Train Anyone... Anywhere.

Chris Smith - Lead Software Developer/Technical Trainer
MindIQ Corporation

java-programmer >> Differences between C++ and Java Chris Smith sez:
> Dimitri Maziuk <email***@***.com> wrote:
>> I have, and I much prefer Delphi language guide that says object
>> references are "pointers that are automatically dereferenced"
>
> And that's Delphi. It doesn't make sense to say that in Java. In Java,
> a reference is only dereferenced if you apply an operation that
> dereferences it. Those operations include the "." and "[]" symbols, and
> Java 1.5's unboxing conversions. Otherwise, there is no dereferencing
> that takes place.

What they mean by "automatically dereferenced" is you don't write
(using C syntax as it's probably more familiar) myobj->myfunc(),
you write myobj.myfunc(). It doesn't make sense in Java because
there is no "->" in Java, yet if reference values are pointers
(as per JLS) "." must involve dereferencing behind the scenes.

> I see that language in 4.12.3 in the JLS 3rd edition, and 4.5.3 in the
> JLS 2nd edition. Are you sure you're reading the same JLS as the rest
> of us?

Sun's website, 1.5 docs, JLS 3rd edition, #4.3 "reference types and
values" and #8.4 "formal parameters".

> I don't know much about Delphi, but the language above about references
> being automatically dereferenced suggests that it's not exactly the
> same. If use of a reference as an lvalue in Delphi modifies the object
> and not the reference, then it is different in precisely the way that is
> needed in order to make Delphi qualify as pass by reference in a way
> that Java does not.

No, it's just that Delphi documentation is written for people who are
used to regular meaning of certain terms -- as opposed to Java meaning.

In Delphi "by reference" means "var parameter". The default is by
value and language guide explains that "by value" involves making
a copy of the variable. Like in Java, assignment to a "class type
variable" (Java "reference value") re-points the pointer. You can't
change that because like Java Delphi does not allow operator
overloading. (I'm assuming by "lvalue" you mean "can be assigned to").

What makes the comparison interesting is that both languages were
developed at the same time and both teams came up with the same
way of handling objects.

Dima
--
Relativity, Uncertainty, Incompleteness, Undecidability: choose any four