++i is faster than i++ in Java?

[Stefan Schulz]

Java does not (yet) allow operator overloading, so the issue does not arise.

And i sure hope it never does. The tangled mess of C++ should not be
allowed to procreate into the (relatively) pure java programming language.
After all, there was a reason why pointer arithmetics and operator
overloading where not introduced in the first place.

 

[Dimitri Maziuk]

["Followup-To:" header set to comp.lang.java.programmer.]
Stefan Schulz sez:

And i sure hope it never does. The tangled mess of C++ should not be
allowed to procreate into the (relatively) pure java programming language.
Bwahahahaha.

After all, there was a reason why pointer arithmetics and operator
overloading where not introduced in the first place.

Wrong. There were two different reasons: pointer arithmetics isn't
there because "there are no pointers". Operator overloading isn't
there because Java is not really a modern high-level language.
(Any modern HLL allows one to make user-defined types look and
behave like native ones. In Java it's not possible anyway due
to stack/heap allocations, so why bother with operator overloading.)

HTH, HAND
Dima

 

[Thomas Hawtin]

Wrong. There were two different reasons: pointer arithmetics isn't
there because "there are no pointers".

No pointers was a marketing contraction for no pointer arithmetic. So
you are saying that there is no pointer arithmetic because there is no
pointer arithmetic. I don't think that gets us anywhere.

Operator overloading isn't
there because Java is not really a modern high-level language.
(Any modern HLL allows one to make user-defined types look and
behave like native ones. In Java it's not possible anyway due
to stack/heap allocations, so why bother with operator overloading.)

That's sorted that one out.

Tom Hawtin

 

[Roedy Green]

Wrong. There were two different reasons: pointer arithmetics isn't
there because "there are no pointers". Operator overloading isn't
there because Java is not really a modern high-level language.
(Any modern HLL allows one to make user-defined types look and
behave like native ones. In Java it's not possible anyway due
to stack/heap allocations, so why bother with operator overloadin

That is about the most idiotic piece of nonsense I have ever read.

If there were arithmetic supported on the references they would be
called pointers.

What you effectively said is "Java has no pointer arithmetic because
the designers chose not to allow pointer arithmetic."

Your second statement is equally mad. It amounts to saying ":I
consider operator overloading to be a necessary feature of a modern
high level language. The reason Java designers left out the feature
was to leave out the feature."

You are not only a troll, an incomprehensible troll.

 

[Dimitri Maziuk]

Roedy Green sez:

That is about the most idiotic piece of nonsense I have ever read.

If there were arithmetic supported on the references they would be
called pointers.

You're confused. A reference is a piece of data that refers to
data stored elsewhere. Pointers a simple implementation, but
not the only one. There's no pointer arithmetic on references
because references are not pointers. They may be implemented
as pointers behind the scenes, but that's an implementation
detail.

Repeat after me until you memorize this: "references are not
pointers. References are not pointers. References are not pointers."

What you effectively said is "Java has no pointer arithmetic because
the designers chose not to allow pointer arithmetic."

No, what I said was Java has no pointer arithmetics because Java
has no pointers. Or user-manageable memory, for that matter.

Your second statement is equally mad. It amounts to saying ":I
consider operator overloading to be a necessary feature of a modern
high level language. The reason Java designers left out the feature
was to leave out the feature."

Operator overloading is mainly used to make user-defined types
look like the "first class citizens". In Java that isn't possible
by design: UDT's are allocated on the heap whereas native types
are allocated on stack, and that makes all the difference. E.g.:
x=y
y=z
Q: what does x equal to: y or z?
A: it depends: z if they're UDT's, y if they're native types.

Operator overloading on top of this is like "a new paint job on
a haunted house".

You are not only a troll, an incomprehensible troll.

Learning how computers work will really help with comprehension
of computer-related texts (hint).

Dima

 

[Roedy Green]

Repeat after me until you memorize this: "references are not
pointers. References are not pointers. References are not pointers."

I did not say that references are the same thing as pointers. I said
that the defining characteristic of a pointer is the ability to do
arithmetic on them so you are spouting meaningless tautologies.

 

[Mike Schilling]

Roedy Green sez:

You're confused. A reference is a piece of data that refers to
data stored elsewhere.

As are pointers. In fact, Java references are exactly the same thing as
Pascal pointers. And both are opaque; you can't see how they're impemented.

Pointer arithmetic come from the C/C++ conflation of arrays and pointers,
which is presenrt in neither Java nor Pascal.

Operator overloading is mainly used to make user-defined types
look like the "first class citizens". In Java that isn't possible
by design: UDT's are allocated on the heap whereas native types
are allocated on stack, and that makes all the difference. E.g.:
x=y
y=z
Q: what does x equal to: y or z?
A: it depends: z if they're UDT's, y if they're native types.

OK, now I'm going to stop listening, because this is utter nonsense. In
both cases x is equal to the original value of y

 

[Mike Schilling]

I did not say that references are the same thing as pointers. I said
that the defining characteristic of a pointer is the ability to do
arithmetic on them so you are spouting meaningless tautologies.

It comes, I think, from only knowing one language that uses the term
"pointer".

 

[Dimitri Maziuk]

Mike Schilling sez:

As are pointers. In fact, Java references are exactly the same thing as
Pascal pointers. And both are opaque; you can't see how they're impemented.

Pointer arithmetic come from the C/C++ conflation of arrays and pointers,
which is presenrt in neither Java nor Pascal.

Oh, that clears things up. C.f.

OK, now I'm going to stop listening, because this is utter nonsense. In
both cases x is equal to the original value of y

void add1( int x ) { x += 1; }
void add2( StringBuffer x ) { x.append( 2 ); }
int i = 1;
StringBuffer buf = new StringBuffer( "u" );
add1( i );
add2( buf );
System.out.println( i + ", " + buf );

Are you saying this will print "1, u"?

Dima

 

[Benji]

Operator overloading is mainly used to make user-defined types
look like the "first class citizens". In Java that isn't possible
by design: UDT's are allocated on the heap whereas native types
are allocated on stack, and that makes all the difference. E.g.:
x=y
y=z
Q: what does x equal to: y or z?
A: it depends: z if they're UDT's, y if they're native types.

Uh...yeah, you don't know what you're talking about.

 

[Benji]

void add1( int x ) { x += 1; }
void add2( StringBuffer x ) { x.append( 2 ); }
int i = 1;
StringBuffer buf = new StringBuffer( "u" );
add1( i );
add2( buf );
System.out.println( i + ", " + buf );

Are you saying this will print "1, u"?

That's a completely different question. Go write a test program for your
x/y/z example and see that it doesn't do what you thought it does.

 

[Benji]

Operator overloading is mainly used to make user-defined types
look like the "first class citizens". In Java that isn't possible
by design: UDT's are allocated on the heap whereas native types
are allocated on stack, and that makes all the difference. E.g.:
x=y
y=z
Q: what does x equal to: y or z?
A: it depends: z if they're UDT's, y if they're native types.

Uh...yeah, I don't think you meant what you typed...

think about it again.

 

[Mike Schilling]

Mike Schilling sez:

Oh, that clears things up. C.f.


void add1( int x ) { x += 1; }
void add2( StringBuffer x ) { x.append( 2 ); }
int i = 1;
StringBuffer buf = new StringBuffer( "u" );
add1( i );
add2( buf );
System.out.println( i + ", " + buf );

Are you saying this will print "1, u"?

Since this isn't an instance of

x=y
y=z

I wasn't saying anything about it.

 

[Roedy Green]

It comes, I think, from only knowing one language that uses the term
"pointer".

Certainly assembler, C, C++ all allow pointer arithmetic.

PL/1 ptr/pointer is untyped. You can set them with the ADDR pseudo
function to objects (level 01) or field in objects (level 02) or even
individual elements of arrays. Using a feature similar to C unions you
can fiddle pointers to your hearts content.

It has been a while since I wrote Pascal, but IIRC Pascal pointers
are typed. e.g. ^treenode; They behave similarly to Java references
with the exception that there is no gc. You have to use a manual
dispose. You also have to keep your wits about you whether you want
p:=q (to copy pointers) or p^:=q^ (copy the objects pointed to).
I don't recall a way of getting a pointer other than via new, so I
think these are half way between Java references and C pointers.

Since the term pointer is used in so many contexts you can't very well
claim any authorative definition. Here though are the factors that I
think any definition would likely consider:


Pointer attributes:
1. close to the hardware, an absolute or relative hardware address
2. can point in to the middle of objects.
3. can do arithmetic on a pointer via some sort of kludge.

Reference attributes:
1. the bits of the representation is not accessible to examine or
change as bits/numbers.
2. they always point to objects as a whole, never to fields in an
object..
3. garbage collection of objects.
4. the inability to accidentally reference memory other than to a
valid object.

 

[Roedy Green]

Certainly assembler, C, C++ all allow pointer arithmetic.

and Forth works that way too.

Oberon supports POINTER TO only to records, not primitives similar to
Pascal. It uses a more Javaesque syntax than Pascal with automatic
pointer dereferencing. e.g. you can say p.Next:=q.Next;
Oberon has gc and also manual allocation. It is very close to Java. So
I would call what Oberon does references.

 

[Mike Schilling]

Certainly assembler, C, C++ all allow pointer arithmetic.

PL/1 ptr/pointer is untyped. You can set them with the ADDR pseudo
function to objects (level 01) or field in objects (level 02) or even
individual elements of arrays. Using a feature similar to C unions you
can fiddle pointers to your hearts content.

It has been a while since I wrote Pascal, but IIRC Pascal pointers
are typed. e.g. ^treenode; They behave similarly to Java references
with the exception that there is no gc. You have to use a manual
dispose. You also have to keep your wits about you whether you want
p:=q (to copy pointers) or p^:=q^ (copy the objects pointed to).
I don't recall a way of getting a pointer other than via new, so I
think these are half way between Java references and C pointers.

There's exactly like Java references in most ways:

1. They only point to dynamically created objects.
2. They're strongly typed.
3. The only operations defined on them are copying to another pointer and
dereference. (And, in Pascal, "free").

They're different, in that, in Pascal, any type of object can be allocated
either on the stack or the heap, while in Java, scalars are always on the
stack and objects (record types in Pascal) on the heap.

 

[Dimitri Maziuk]

Benji sez:

That's a completely different question.

Why? Because the assignment takes place in a subroutine
or because it uses append() instead of "operator +"?

All native types are by-value, all UDT's are by-reference.
Simplified illustration of resulting semantic inconsistency is
"x=y; y=z;", do I really have to spell it out in working code?

I guess an average Java weenie won't acknowledge the problem
even if it panted itself blue and danced on the keyboard naked...

Dima

 

[Benji]

All native types are by-value, all UDT's are by-reference.
Simplified illustration of resulting semantic inconsistency is
"x=y; y=z;", do I really have to spell it out in working code?

UDTs are assigned by-value-of-the-reference. This is not c++ pass-by-ref.
Assignment is not a mutating operation for the object, just the reference
variable. This is a really simple problem that I originally thought you
had just mistyped, but now I think you have a fundamental misunderstanding
of what is going on.

public class Test
{
public static void main(String[] argv) {
String x;
String y = "Ben is right";
String z = "Dimitri is right";

x=y;
y=z;

System.out.println(x);
}
}

An example that *would* illustrate the difference would be calling a
mutator on an object, and seeing that two references point to the
same object. But that's not nearly the same thing as what you were
talking about.

I guess an average Java weenie won't acknowledge the problem
even if it panted itself blue and danced on the keyboard naked...

I would be careful about throwing around insults when you don't know
what you're talking about. =)

 

[Mike Schilling]

An example that *would* illustrate the difference would be calling a
mutator on an object, and seeing that two references point to the
same object. But that's not nearly the same thing as what you were
talking about.

In a sense, all this proves is that primitives are immutable.

 

[Roedy Green]

All native types are by-value, all UDT's are by-reference.
Simplified illustration of resulting semantic inconsistency is
"x=y; y=z;", do I really have to spell it out in working code?

We have gone over this hundreds of times before. Java passes
everything by value including references. The problem is in your
understanding, not in Java.

See http://mindprod.com/jgloss/callbyreference.html
http://mindprod.com/jgloss/callbyvalue.html